Re: Building GLIBC
On Tuesday 27 April 2004 05:12 pm, Bob Proulx wrote:
> 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.
Its possible I jumped into this with more ego than good sense but
the decision was not just a whim. My system is badly broken
and the problems seem to center around glibc. I get seg faults
in glibc in routines that have no input parameters so I can't
suspect bad input data.
> > 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.
> 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.
My bad. If startx as root, it runs twm which works. If I startx as a user,
it tries to start Kde which doesn't work. I have been a little lazy about
changing the config files.
> > 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
> cd build-tree/ia64-libc
Thanks, this could help me.
> > 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
Well, I guess I have a lot of learning to do. I do spend a considerable
amount of time just reading documentation and I learn even more
when I experiment. Thanks again for your comments.