Re: Building GLIBC

[bob@proulx.com (Bob Proulx)]

Richard Harke wrote:
> Randolph Chung wrote:
> > make -f debian/rules build

> Thanks.  The last (make -f debian/rules build) did indeed work.

The debian/rules file is a Makefile.  glibc is about as complicated as
you can get so starting there is definitely jumping into the deep end.
The above builds using the same build methodology as the package
itself used.

> Unfortunatly, I think it was going to install it, which I definetly
> didn't want.

I don't think the 'build' target will actually go through the install
phase.  But even if it did you should be fine.  If you wade through
the makefile you will find that the install_root is overridden.  So it
should have installed it like this.  That would be in the build
directory and not on your system.

  install_root=$(CURDIR)/debian/tmp-$(curpass)

Besides, you never should be compiling these things as root.  So even
if it did try to install into the system it would be prevented by
normal system permissions, right?  So nothing bad should happen.

> However, it stopped short in the test phase
> because my 2.4.25 kernel is waay too old. (Note irony)
> Also, when I ran it to see what it would say, it said built
> on a 2.6.0 system. I think this means it used 2.6.0
> headers. Also, I wanted to make a small change and test it.
> But after the change it wouldn't run, saying build up to
> date. It obviously didn't go through the source tree and
> check the dates.

glibc is one of the most complicated packages.  It builds in a
subdirectory.

  cd build-tree/ia64-libc
  make

> So I re-ran the whole business. So then it
> apparently unpacked the tarball instead using the source
> tree. So I am back to square zero. Oh yeah, I also wanted
> to run against the current kernel headers, not the ones I might
> install next month.

I don't know where glibc picks up headers during the compilation
phase.  Did I mention that glibc is one of the most complicated
packages?

Bob