Le 22/04/2012 20:23, DJ Lucas wrote: > On 04/22/2012 12:19 PM, Jeremy Huntwork wrote: >> On 4/22/12 11:33 AM, LFS Trac wrote: >>> #3066: Chapter 5 ncurses fails with (old?) gpm on host >>> -------------------------------------+-------------------------------------- >>> Reporter: dj@… | Owner: lfs-book@… >>> Type: task | Status: new >>> Priority: normal | Milestone: 7.2 >>> Component: Book | Version: SVN >>> Severity: normal | Keywords: >>> -------------------------------------+-------------------------------------- >>> Host system is again Gentoo Live DVD 2011. I had to add --without-gpm to >>> the configure flags to get around it. >> (I tried updating the ticket in trac, but that required me resetting my >> password and now the site puts me in an infinite redirect loop... trac >> is being wonky) >> >> Anyway, unless ncurses is doing something non-standard to detect gpm, I >> don't think this should be happening. The point of the chapter 5 >> toolchain is to remove /usr or anything like it from the search paths. >> DJ can you dig in the logs to find out what ncurses is doing to detect >> gpm? In the meantime, I've downloaded the gentoo live dvd and am going >> to play a bit. >> >> JH > As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is > not a symlink, but rather a linker script that points to another linker > script that points to an invalid destination (ie: no 64bit libgpm). I > was going to close as invalid, but then I wondered if we want our > chapter 5 ncurses linked to something that does not exist in the chroot > environment? > > -- DJ Lucas Hi,
There is still a big flaw in LFS SVN, as I said in http://linuxfromscratch.org/pipermail/lfs-dev/2012-March/066119.html Usually, when testing the presence of a library, configure tries first to include the corresponding header file into a short program (using gcc), then to link to the library. If /usr/include is in the search path of gcc, it may find a header on the host, and then bomb out because it does not find the library, since the search path for libraries does not include {,/usr}/lib. This happened to me twice : first on fedora, which has selinux by default: coreutils could not build because it wanted selinux libraries. Second on Debian with gpm, where I saw the same error as the bug which started this thread. Solution: add the switch --with-native-system-header-dir=/tools/include to gcc-pass2 configure command. I've been building ten times on various (virtual) hosts with this switch without a problem. Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
