Re: LFS-6.6, Stage2, glibc, nscd.c:442
Paul Rogers wrote: >> shouldn't be a cross compiler. IE, it shouldn't have been configured >> with --target=$LFS_TGT. I wonder if the people reporting these errors >> mistakenly used the option --target=$LFS_TGT when they compiled gcc the >> second time in chapter 5? > > Yes, I can definitely confirm it was NOT in my Stage2 script. > > I got around the nscd error with: > > sed -i 's/fstack/fno-stack/' nscd/Makefile > > Then this evening I made a copy of the script without that line > and recompiled glibc with the Stage2 compiler as the next step. > No problem this time. So I think I have a fairly straightforward > workaround. I don't imagine there was any need for the nscd code > to get through the gcc compile. Now I think I have a good glibc > for the rest of the Stage2 build. Onward! So the problem was the Chapter 5 gcc? Let me review. I know you said your base host was LFS 6.1. Are you going directly to LFS 6.6 or an intermediate version? > I do have some errors to check out: > make[2]: *** [/usr/local/src/glibc-build/posix/tst-vfork3.out] Error 1 > make[2]: [/usr/local/src/glibc-build/posix/annexc.out] Error 1 (ignored) > make[1]: *** [posix/tests] Error 2 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-mutex8.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cond8.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-sem11.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-sem12.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancel24.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx4.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx5.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx16.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx20.out] Error 1 > make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx21.out] Error 1 > make[1]: *** [nptl/tests] Error 2 > make: *** [check] Error 2 Those seem fairly familiar to me for older systems. There may be some timing issues. annexc *always* fails. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
> shouldn't be a cross compiler. IE, it shouldn't have been configured > with --target=$LFS_TGT. I wonder if the people reporting these errors > mistakenly used the option --target=$LFS_TGT when they compiled gcc the > second time in chapter 5? Yes, I can definitely confirm it was NOT in my Stage2 script. I got around the nscd error with: sed -i 's/fstack/fno-stack/' nscd/Makefile Then this evening I made a copy of the script without that line and recompiled glibc with the Stage2 compiler as the next step. No problem this time. So I think I have a fairly straightforward workaround. I don't imagine there was any need for the nscd code to get through the gcc compile. Now I think I have a good glibc for the rest of the Stage2 build. Onward! I do have some errors to check out: make[2]: *** [/usr/local/src/glibc-build/posix/tst-vfork3.out] Error 1 make[2]: [/usr/local/src/glibc-build/posix/annexc.out] Error 1 (ignored) make[1]: *** [posix/tests] Error 2 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-mutex8.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cond8.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-sem11.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-sem12.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancel24.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx4.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx5.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx16.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx20.out] Error 1 make[2]: *** [/usr/local/src/glibc-build/nptl/tst-cancelx21.out] Error 1 make[1]: *** [nptl/tests] Error 2 make: *** [check] Error 2 -- Paul Rogers paulgrog...@fastmail.fm http://www.xprt.net/~pgrogers/ Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.fm - IMAP accessible web-mail -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
> I've just done some googling on the subject today and it seems that when > gcc is compiled as a cross compiler it can cause the "undefined > reference to `__stack_chk_guard'" error. Of course, the version of gcc > being used in chroot, the second version of gcc compiled in chapter 5, > shouldn't be a cross compiler. IE, it shouldn't have been configured > with --target=$LFS_TGT. I wonder if the people reporting these errors > mistakenly used the option --target=$LFS_TGT when they compiled gcc the > second time in chapter 5? I'm not on that box at the moment, but I'll double check my script. Retrying the compile with the Stage2 gcc was next on my list anyhow. "News at 11." -- Paul Rogers paulgrog...@fastmail.fm http://www.xprt.net/~pgrogers/ Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.fm - Send your email first class -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
Neal Murphy wrote: > On Thursday 03 June 2010 14:45:04 Chris Staub wrote: >> On 06/03/2010 11:33 AM, Neal Murphy wrote: >>> On Thursday 03 June 2010 04:08:33 Simon Geard wrote: > IIRC, the problem became apparent when the toolchain perl tried to > run in the chroot jail during the final build (Ch. 6 equivalent) > before the final build of perl. It didn't matter what I did; > toolchain perl always built with support for libgdbm and would fail > because it couldn't find that lib in the chroot jail. It built in > support for libgdbm because it found gdbm libs and headers on my > Debian host. It found those things because the '-Dstatic_ext' option > does not prevent it from doing so. Hmm. I wonder why the incorrect behavior doesn't show up for me. On my current svn build, I do not have libgdbm in /tools, but I do have it in the final /usr/lib. ldd on perl does shows: # ldd perl linux-vdso.so.1 => (0x7fffb53ff000) libnsl.so.1 => /lib/libnsl.so.1 (0x7f912c312000) libdl.so.2 => /lib/libdl.so.2 (0x7f912c10e000) libm.so.6 => /lib/libm.so.6 (0x7f912be8c000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x7f912bc55000) libutil.so.1 => /lib/libutil.so.1 (0x7f912ba52000) libc.so.6 => /lib/libc.so.6 (0x7f912b6f6000) /lib64/ld-linux-x86-64.so.2 (0x7f912c52a000) The tools version gives me: # ldd perl linux-vdso.so.1 => (0x7fffe93ff000) libnsl.so.1 => /tools/lib/libnsl.so.1 (0x7f342df99000) libdl.so.2 => /tools/lib/libdl.so.2 (0x7f342dd95000) libm.so.6 => /tools/lib/libm.so.6 (0x7f342db13000) libcrypt.so.1 => /tools/lib/libcrypt.so.1 (0x7f342d8dc000) libutil.so.1 => /tools/lib/libutil.so.1 (0x7f342d6d9000) libc.so.6 => /tools/lib/libc.so.6 (0x7f342d37d000) libgcc_s.so.1 => /tools/lib/libgcc_s.so.1 (0x7f342d168000) /tools/lib64/ld-linux-x86-64.so.2 (0x7f342e1b1000) I do have libgdm on the host system also. I didn't do the research that is in the book's dependencies section, but it says that perl is needed to build glibc. If it were a general problem, I'd think we would have seen it a long time ago. We may end up adding the extra switches in Chapter 5's perl build, but I'm trying to understand why it's needed on your system and not others before doing that. Figuring that out may be more work than anyone wants to do. > - This oddity has not been reported before (here or anywhere). - This > is not a problem report or support request. - It's a report of > something I encountered whilst using 6.4 as a guide to updating a > project that was originally based on LFS. - To the best of my ability > to determine, perl's configure script explicitly searches the host > filesystem for features it should support, an action which _can_ > poison the toolchain. - I know that the normal 'static_ext' parameter > does not prevent perl's configure from searching the host for > features to support. - I am very sure that the extra four configure > options do prevent perl's configure from potentially poisoning the > toolchain with references to the host ysstem. > > According to Ch. 5, the intent is to have perl build only the four > specified features, and build them statically into perl. As I > understand, the '-Dstatic_ext=...' option that LFS uses tells perl > only to build those features statically into perl. That's the intent, yes. > It doesn't > restrain perl from building other extensions. It doesn't prevent > perl's configure script from searching the host system. > > The real issue is that, as best as I can tell, perl's configure > script searches the host's filesystems for features to support, which > is not desired when building the toolchain. Why it does that to me > when building on Debian Lenny and not to anyone else, I don't know. I > do know that the extra parameters for perl's configure effectively > limit it to searching ONLY the toolchain for features to support. > > Perhaps I was remiss in not putting 'FYI' in the subject, No, not really. We appreciate and thank you for your report. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On Thursday 03 June 2010 14:45:04 Chris Staub wrote: > On 06/03/2010 11:33 AM, Neal Murphy wrote: > > On Thursday 03 June 2010 04:08:33 Simon Geard wrote: > >> Curious... like Chris, I routinely build LFS from a host with gdbm > >> installed (i.e LFS itself), and never observed any problems relating to > >> perl. Indeed, even on completed LFS install, /usr/bin/perl isn't linked > >> against gdbm, and runs fine if I remove the libgdbm libraries. > >> > >> Can you be more specific about the problems you're seeing? Does the perl > >> executable fail to run at all, unable to link to libgdbm.so? Or is it > >> something less obvious? > >> > >> Simon. > > > > I built on Debian Lenny. Perl's configure examines the host system > > looking for useful features. In my case, libgdbm was installed on Lenny; > > perl found it and configured support for it. Later in the the build, perl > > failed to run because it couldn't find libgdbm.so. This was obvious. What > > wasn't obvious was, "Why?" > > Still not enough info. At what point did Perl try to run, and how > exactly? Is it just when running "perl" at all? With certain specific > options and/or using certain Perl modules? IIRC, the problem became apparent when the toolchain perl tried to run in the chroot jail during the final build (Ch. 6 equivalent) before the final build of perl. It didn't matter what I did; toolchain perl always built with support for libgdbm and would fail because it couldn't find that lib in the chroot jail. It built in support for libgdbm because it found gdbm libs and headers on my Debian host. It found those things because the '-Dstatic_ext' option does not prevent it from doing so. > > > If I may be so crass, that you haven't stumbled on this may be due purely > > to dumb luck. There are probably subtle differences between LFS' build > > steps and the steps I follow in my project. > > And this may very well be the issue, since nobody has reported this > problem when building LFS before. I'd say that for this report to have > any validity, you'd need share exactly what these differences are, in > particular how Perl is built in Chapter 5 (of course giving more than > just "adding those 4 options to Configure"). Typically when some package > tries to pull something from the host, it's because of a goof-up in > Chapter 5. - This oddity has not been reported before (here or anywhere). - This is not a problem report or support request. - It's a report of something I encountered whilst using 6.4 as a guide to updating a project that was originally based on LFS. - To the best of my ability to determine, perl's configure script explicitly searches the host filesystem for features it should support, an action which _can_ poison the toolchain. - I know that the normal 'static_ext' parameter does not prevent perl's configure from searching the host for features to support. - I am very sure that the extra four configure options do prevent perl's configure from potentially poisoning the toolchain with references to the host ysstem. According to Ch. 5, the intent is to have perl build only the four specified features, and build them statically into perl. As I understand, the '-Dstatic_ext=...' option that LFS uses tells perl only to build those features statically into perl. It doesn't restrain perl from building other extensions. It doesn't prevent perl's configure script from searching the host system. The real issue is that, as best as I can tell, perl's configure script searches the host's filesystems for features to support, which is not desired when building the toolchain. Why it does that to me when building on Debian Lenny and not to anyone else, I don't know. I do know that the extra parameters for perl's configure effectively limit it to searching ONLY the toolchain for features to support. Perhaps I was remiss in not putting 'FYI' in the subject, for it was my intent to save the next guy a lot of time tracking down something that is only a problem when building a toolchain, something that involves unclearly documented options. I don't dispute that the LFS build works. I've tried to avoid denigrating anyone's efforts. I offered the arcane, obscure info not to trick people into spinning their wheels, but rather to help make LFS better, more correct, and more bullet-proof.-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: libmng-1.0.10
On Thursday 03 June 2010 12:49:36 Ken Moffat wrote: > > until after qt or maybe kde. Anyhow I guess I'm just looking for a bit of > > hand holding and posting to see if a ticket regarding this is warranted. > > I used to see it (I stopped building libmng over a year ago because I > couldn't find any need for it). In my case I used to > > sed -e 's%-O3%-O3 -fPIC%' \ > makefiles/makefile.linux >Makefile > > which is nearly the same as you are doing.. Thanks, that makes me feel better during the many hours until everything is built; honestly, I don't know if I have ever seen an MNG file. > I also have to force it in a52dec-0.7.4 (add to CFLAGS when running > configure) and ghostscript-8.70 where I took the fix from cblfs and > adapted it when the file moved - > sed -i "s/CFLAGS='/&-fPIC /g" base/unix-dll.mak > > When I first played with pure64 there were several other packages > that needed fPIC added. Slowly, the old ones are either being relaced > or dropping out of use. Thanks for the heads up. So far I've only run into trouble with libmng and cvs (which I haven't investigated.) I believe both packages have not had a release in the last 2-3 years. -- Regards, Trent. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: libmng-1.0.10
On 3 June 2010 18:41, Trent Shea wrote: > I'm working on my first x86_64 system build using the 6.6 book, and I've run > into a bit of trouble with libmng. > [...] > /usr/bin/ld: libmng_chunk_io.o: relocation R_X86_64_32 against `.rodata' can > not be used when making a shared object; recompile with -fPIC > libmng_chunk_io.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [libmng.so.1.1.0.9] Error 1 > > As suggested I added -fPIC to the build: > diff makefiles/makefile.linux > /media/data.castra/build/libmng-1.0.10/makefiles/makefile.linux > 47c47 > < CFLAGS=-I$(ZLIBINC) -I$(JPEGINC) -I$(LCMSINC) -Wall -O3 -funroll-loops \ > --- >> CFLAGS=-I$(ZLIBINC) -I$(JPEGINC) -I$(LCMSINC) -fPIC -Wall -O3 -funroll-loops > \ > > I'm curious if anyone else has seen this, and if so am I on the right track? I > do see that Debian has added -fPIC to their CFLAGS. I'm afraid there's not a > test suite with this package and I probably won't find out if everything works > until after qt or maybe kde. Anyhow I guess I'm just looking for a bit of hand > holding and posting to see if a ticket regarding this is warranted. > I used to see it (I stopped building libmng over a year ago because I couldn't find any need for it). In my case I used to sed -e 's%-O3%-O3 -fPIC%' \ makefiles/makefile.linux >Makefile which is nearly the same as you are doing.. I also have to force it in a52dec-0.7.4 (add to CFLAGS when running configure) and ghostscript-8.70 where I took the fix from cblfs and adapted it when the file moved - sed -i "s/CFLAGS='/&-fPIC /g" base/unix-dll.mak When I first played with pure64 there were several other packages that needed fPIC added. Slowly, the old ones are either being relaced or dropping out of use. ĸen -- After tragedy, and farce, "OMG poneys!" -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On 06/03/2010 11:33 AM, Neal Murphy wrote: > On Thursday 03 June 2010 04:08:33 Simon Geard wrote: >> >> Curious... like Chris, I routinely build LFS from a host with gdbm >> installed (i.e LFS itself), and never observed any problems relating to >> perl. Indeed, even on completed LFS install, /usr/bin/perl isn't linked >> against gdbm, and runs fine if I remove the libgdbm libraries. >> >> Can you be more specific about the problems you're seeing? Does the perl >> executable fail to run at all, unable to link to libgdbm.so? Or is it >> something less obvious? >> >> Simon. > > I built on Debian Lenny. Perl's configure examines the host system looking for > useful features. In my case, libgdbm was installed on Lenny; perl found it > and configured support for it. Later in the the build, perl failed to run > because it couldn't find libgdbm.so. This was obvious. What wasn't obvious > was, "Why?" Still not enough info. At what point did Perl try to run, and how exactly? Is it just when running "perl" at all? With certain specific options and/or using certain Perl modules? > If I may be so crass, that you haven't stumbled on this may be due purely to > dumb luck. There are probably subtle differences between LFS' build steps and > the steps I follow in my project. And this may very well be the issue, since nobody has reported this problem when building LFS before. I'd say that for this report to have any validity, you'd need share exactly what these differences are, in particular how Perl is built in Chapter 5 (of course giving more than just "adding those 4 options to Configure"). Typically when some package tries to pull something from the host, it's because of a goof-up in Chapter 5. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
> I wouldn't really say they are a "triviality" (given that I am one of > those who did much of the initial testing/research for the HSR's in > the first place) but they *are* just one of many parts of the book > that would need to be checked, though I would argue that they are > slightly less important than other issues (given how rarely we > actually have issues concerning them). Package versions must work > togethers, commands need to be correct, the book's text must be both > technically correct and readable to those new to LFS, etc... Of course. If the package instructions aren't right, whether the HSR's are correct or not doesn't matter. But we agree they aren't a triviality and do need to be checked. Just seems to me someone would (have) setup and preserve(d) a trailer system for that purpose. Guess nobody ever did. > Could there be slight variances in "how" one "enters chroot" that > could possibly affect this? I would't expect that to be likely. I could post my script if necessary. But it uses the same template, 100 lines of self-documentation for less than a dozen lines of executable commands. ;-) I suppose I could cut some of that away, if that weren't to raise questions. > Well we do mount /proc, /sys, /def, /dev/pts, and /dev/shm from the > host system. The glibc build system might be probing something > like /proc. > > Ken's method of first building the LFS target kernel in the host > system and rebooting to that would avoid potential problems here. As somebody wrote a while back, getting a config file that was still compatible with the (back-levelled) host could be a formidable task. Perhaps I didn't spend enough time on that--lots of new stuff there I'd never seen before. It seemed patching up one level was more direct. When I patched from .17 to .18, I built it as a monolithic kernel and cut out some stuff, e.g. sound, to preserve the host's kernel and modules for recovery purposes. When I get back on that box I'm going to check again for CC_STACKPROTECTOR somewhere in .18, just to be sure. > One purpose of LFS (mayhap unstated) is to help the user figure out > how she got to be lost in the midst of the sea in the first place. She > may not know where she is, but she should be able to determine just > how she got there. LFS is, in a manner of speaking, navigation by dead > reckoning. Everything should work. But sometimes your instruments are > slightly out of calibration, and one step leaves you 'elsewhere'. > After that, the rest of the journey is flawed. I might debate "flawed", by my connotations. Not recommended perhaps. But if one can establish where elsewhere is, and where the goal is relative to elsewhere, one might be able to chart a course to the goal, and come out where one wanted to go. It's how some "exploration" is done. ;-) Yes, some explorers are never heard from again--that's why they post their planned route at the trailhead. I haven't given-up trying to get there from here. Mayhap I'll pickup some disease along the way, but I don't think necessarily so. I can boil the water. > By-and-large, LFS is a great guide. The only real deficiency I've > found is in the configure options for perl; it took me a week to dig > through that script (and some source code) to find out why the > toolchain perl insisted on on needing libgdbm; simply, it was doing > exactly what it should: build to include all optional features it > finds on the host. That, of course, poisons the toolchain. I think deciding on what it "should" do should be based on instruction. In my case, I don't even NEED nscd, but I'm not given an option, without hacking one in, of course. > So, by all means, more power to LFS! In some senses at least. ;-) > > If I'm reading those correctly the problem happens when newer > > versions of gcc are compiled against an older version of glibc, > > which begs the question, why was Paul Rogers getting the "undefined > > reference to __stack_chk_guard" error in chapter 6? At that point > > the gcc he was using should have been compiled against the new glibc > > in /tools Or am I missing something? > > Nope. I think that's the nub of it. I also think it's a question worth > trying to answer. How can I help? (While I slog on, of course.) I've got my scripts--it wasn't all typed in and rolled off screen. > I agree that the problem you have uncovered is worth pursuing down to > root cause. Until we understand the root cause, we can't be sure it > won't come up again in the future. When it is understood, then either > a prevention in the sense of what a minimal HSR is can be done, or a > prevention in the sense of a patch to the build can be done. > No, you do not have to build 6.3 at all. You only have to use 6.3. I'm > fairly certain that 6.3 is capable of building 6.6, ahd you can use > 6.3 without building it. May I suggest that would be true if you had written it "in the first person." I believe I already explained how my goals differ than just
libmng-1.0.10
I'm working on my first x86_64 system build using the 6.6 book, and I've run into a bit of trouble with libmng. gcc -shared -Wl,-soname,libmng.so.1 -o libmng.so.1.1.0.9 \ libmng_callback_xs.o libmng_chunk_io.o libmng_chunk_descr.o libmng_chunk_prc.o libmng_chunk_xs.o libmng_cms.o libmng_display.o libmng_dither.o libmng_error.o libmng_filter.o libmng_hlapi.o libmng_jpeg.o libmng_object_prc.o libmng_pixels.o libmng_prop_xs.o libmng_read.o libmng_trace.o libmng_write.o libmng_zlib.o -L/usr/local/lib -L/usr/local/lib -ljpeg -L/usr/local/lib -llcms \ -lz -lm -lc /usr/bin/ld: libmng_chunk_io.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC libmng_chunk_io.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [libmng.so.1.1.0.9] Error 1 As suggested I added -fPIC to the build: diff makefiles/makefile.linux /media/data.castra/build/libmng-1.0.10/makefiles/makefile.linux 47c47 < CFLAGS=-I$(ZLIBINC) -I$(JPEGINC) -I$(LCMSINC) -Wall -O3 -funroll-loops \ --- > CFLAGS=-I$(ZLIBINC) -I$(JPEGINC) -I$(LCMSINC) -fPIC -Wall -O3 -funroll-loops \ I'm curious if anyone else has seen this, and if so am I on the right track? I do see that Debian has added -fPIC to their CFLAGS. I'm afraid there's not a test suite with this package and I probably won't find out if everything works until after qt or maybe kde. Anyhow I guess I'm just looking for a bit of hand holding and posting to see if a ticket regarding this is warranted. Oh, to test later: http://www.libmng.com/MNGsuite/index.html -- Regards, Trent. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
Neal Murphy wrote:
> On Thursday 03 June 2010 04:08:33 Simon Geard wrote:
>> Can you be more specific about the problems you're seeing? Does the perl
>> executable fail to run at all, unable to link to libgdbm.so? Or is it
>> something less obvious?
>>
>> Simon.
>
[...]
>
> That's when I dug into perl's configure script and eventually discovered that
> LFS' standard two config options are not enough to adequately shield the
> toolchain build from the host system. Given the scant documentation, you'd
That's very interesting. Back in the past when I worked on a compiler
I helped develop, we often ran into places where we couldn't test a
"fix" unless we compiled, then compiled with the new object, then
compiled again, etc. IIRC, at one time it took four recompiles to
expunge the problem. I recall several times when we'd argue (there were
two of us on the dev team) about whether we had done it enough, because
it was so difficult to figure out exactly what wound up in the
executable.
> think '-Dstatic_ext='Data/Dumper Fcntl IO POSIX' would be enough. It isn't.
> You also have to tell it to build ONLY those extensions, to look ONLY
> in /tools/lib for libraries, and to look ONLY in /tools/include for headers.
> (Alas, a year later, I don't remember why the inc_version_list is necessary.)
>
> If you don't add these four options, perl's configure will spelunk through
> the
> HOST's tree looking for features it should support. This behaviour is EXACTLY
> what most people want when they build and install perl on their running
> system. Alas, it is exactly what you do NOT want when building a bootstrap
> toolchain.
Sounds like a difficult find, and an easy fix. Thanks for reporting
back. I wonder how it escapes the chroot environment. Ah, I see,
when the /tools/* stuff gets built, Perl puts it into there, and
then when building in the chroot, it's in /tools, so it puts it in, and
then there's a problem after reboot.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On Thursday 03 June 2010 04:08:33 Simon Geard wrote: > On Thu, 2010-06-03 at 02:39 -0400, Neal Murphy wrote: > > On Thursday 03 June 2010 00:30:58 Chris Staub wrote: > > > I just built Perl in Chapter 5, and I do have gdbm installed (this is > > > on a couple-week-old LFS svn host system). I get " NOT found." > > > during Configure, and it doesn't look like anything in Perl tries to > > > link to libgdbm. > > > > Dig deep. Perl's configure, trying to be ever-so-helpful, finds it > > (libgdbm.*) on the host (your LFS SVN host) and configures support for > > the package. > > Curious... like Chris, I routinely build LFS from a host with gdbm > installed (i.e LFS itself), and never observed any problems relating to > perl. Indeed, even on completed LFS install, /usr/bin/perl isn't linked > against gdbm, and runs fine if I remove the libgdbm libraries. > > Can you be more specific about the problems you're seeing? Does the perl > executable fail to run at all, unable to link to libgdbm.so? Or is it > something less obvious? > > Simon. I built on Debian Lenny. Perl's configure examines the host system looking for useful features. In my case, libgdbm was installed on Lenny; perl found it and configured support for it. Later in the the build, perl failed to run because it couldn't find libgdbm.so. This was obvious. What wasn't obvious was, "Why?" Perl wouldn't run and my build failed. As I said in another post, "Dere I was, mindtin' my own bidness, when all of a sudden, I was lost at sea." Instad of panicking, I retraced my steps to determine how I got there. That retracement led me to perl and its obsequious assistance. That's when I dug into perl's configure script and eventually discovered that LFS' standard two config options are not enough to adequately shield the toolchain build from the host system. Given the scant documentation, you'd think '-Dstatic_ext='Data/Dumper Fcntl IO POSIX' would be enough. It isn't. You also have to tell it to build ONLY those extensions, to look ONLY in /tools/lib for libraries, and to look ONLY in /tools/include for headers. (Alas, a year later, I don't remember why the inc_version_list is necessary.) If you don't add these four options, perl's configure will spelunk through the HOST's tree looking for features it should support. This behaviour is EXACTLY what most people want when they build and install perl on their running system. Alas, it is exactly what you do NOT want when building a bootstrap toolchain. If I may be so crass, that you haven't stumbled on this may be due purely to dumb luck. There are probably subtle differences between LFS' build steps and the steps I follow in my project. As my project was originally based on LFS (many years ago), I thought it only fair that I share what I found about this particular problem; mayhap I could save someone a lot of time. If nothing else, some day y'all'll trip on it and the solution'll be here in the archives, waiting to be discovered again. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Can't set $PS1 properly under Ubuntu 10.04 host
littlebat wrote: > Hi, > > I am learning: 4.4. Setting Up the Environment: > http://www.linuxfromscratch.org/lfs/view/6.6/chapter04/settingenvironment.html > . My host system is Ubuntu 10.04. > > I found it can't properly to set $PS1 for user "lfs" with the command > below provided by LFS6.6 book under Ubuntu 10.04 host system. cat > ~/.bash_profile << "EOF" exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash EOF > The reason is Ubuntu will setup PS1 in /etc/bash.bashrc, so I think > maybe we should set this value in ~/.bashrc ? No, that's not how it works. Upon login as the lfs user, bash executes /etc/profile $HOME/.bash_profile in that order. The 'exec env -i' portion ignores the environment that was set by /etc/profile. The second part sets up 3 and only 3 environment variables. bash itself sets up a few more, but not PS1. $HOME/.bashrc is not run by default in an initial login. Make sure you are doing an initial login. su - lfs The dash is important. Without it, $HOME/.bash_profile is not run and only $HOME/.bashrc is run. Other sub-shells that are run by the lfs user do use $HOME/.bashrc Take a look at the invocation portion of the bash man page and also at the env man page. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Can't set $PS1 properly under Ubuntu 10.04 host
Hi,
I am learning: 4.4. Setting Up the Environment:
http://www.linuxfromscratch.org/lfs/view/6.6/chapter04/settingenvironment.html
. My host system is Ubuntu 10.04.
I found it can't properly to set $PS1 for user "lfs" with the command below
provided by LFS6.6 book under Ubuntu 10.04 host system.
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF
The reason is Ubuntu will setup PS1 in /etc/bash.bashrc, so I think maybe we
should set this value in ~/.bashrc ?
And, my linux skill is poor, I don't know if the setup in /etc/bash.bashrc in
Ubuntu will break something other of LFS building environment.
Below is the content of /etc/bash.bashrc in Ubuntu 10.04:
# System-wide .bashrc file for interactive bash(1) shells.
# To enable the settings / commands in this file for login shells as well,
# this file has to be sourced in /etc/profile.
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
# set a fancy prompt (non-color, overwrite the one in /etc/profile)
PS1='${debian_chroot:+($debian_chroot)}...@\h:\w\$ '
# Commented out, don't overwrite xterm -T "title" -n "icontitle" by default.
# If this is an xterm set the title to u...@host:dir
#case "$TERM" in
#xterm*|rxvt*)
#PROMPT_COMMAND='echo -ne "\033]0;${us...@${hostname}: ${PWD}\007"'
#;;
#*)
#;;
#esac
# enable bash completion in interactive shells
#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
#. /etc/bash_completion
#fi
# sudo hint
if [ ! -e "$HOME/.sudo_as_admin_successful" ]; then
case " $(groups) " in *\ admin\ *)
if [ -x /usr/bin/sudo ]; then
cat <<-EOF
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.
EOF
fi
esac
fi
# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found ]; then
function command_not_found_handle {
# check because c-n-f could've been removed in the meantime
if [ -x /usr/lib/command-not-found ]; then
/usr/bin/python /usr/lib/command-not-found -- $1
return $?
elif [ -x /usr/share/command-not-found ]; then
/usr/bin/python /usr/share/command-not-found -- $1
return $?
else
return 127
fi
}
fi
--
littlebat
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
On 03/06/10 05:22, Mike McCarty wrote: > Andrew Benton wrote: >> If I'm reading those correctly the problem happens when newer versions >> of gcc are compiled against an older version of glibc, which begs the >> question, why was Paul Rogers getting the "undefined reference to >> __stack_chk_guard" error in chapter 6? At that point the gcc he was >> using should have been compiled against the new glibc in /tools >> Or am I missing something? > > Nope. I think that's the nub of it. I also think it's a question > worth trying to answer. > I've just done some googling on the subject today and it seems that when gcc is compiled as a cross compiler it can cause the "undefined reference to `__stack_chk_guard'" error. Of course, the version of gcc being used in chroot, the second version of gcc compiled in chapter 5, shouldn't be a cross compiler. IE, it shouldn't have been configured with --target=$LFS_TGT. I wonder if the people reporting these errors mistakenly used the option --target=$LFS_TGT when they compiled gcc the second time in chapter 5? Andy -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS-6.6, Stage2, glibc, nscd.c:442
On Wed, 2010-06-02 at 17:05 -0700, Paul Rogers wrote: > And if that leads some of us to scoff at the idea of dragons, it has, in > fact, done the job. Oh, I don't scoff at the idea of dragons - I just don't recommend stopping and asking them for directions. :) Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: perl, gdbm and perl's obsequious help
On Thu, 2010-06-03 at 02:39 -0400, Neal Murphy wrote: > On Thursday 03 June 2010 00:30:58 Chris Staub wrote: > > I just built Perl in Chapter 5, and I do have gdbm installed (this is on > > a couple-week-old LFS svn host system). I get " NOT found." > > during Configure, and it doesn't look like anything in Perl tries to > > link to libgdbm. > > Dig deep. Perl's configure, trying to be ever-so-helpful, finds it > (libgdbm.*) > on the host (your LFS SVN host) and configures support for the package. Curious... like Chris, I routinely build LFS from a host with gdbm installed (i.e LFS itself), and never observed any problems relating to perl. Indeed, even on completed LFS install, /usr/bin/perl isn't linked against gdbm, and runs fine if I remove the libgdbm libraries. Can you be more specific about the problems you're seeing? Does the perl executable fail to run at all, unable to link to libgdbm.so? Or is it something less obvious? Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
