[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
>   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.
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
> subdirectory.
>   cd build-tree/ia64-libc
>   make
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
> packages?
> Bob
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.


Reply to: