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. Richard
