On 08/22/15 13:52, Bruce Dubbs wrote: > Pi LFS wrote: >> On 08/22/2015 01:15 AM, xinglp wrote: >>> The error is "cannot find -lmvec". I tried to use "--disable-mathvec", >>> but not work. >>> >>> more log: >>> ======================== >>> then echo 'stubs.h unchanged'; \ >>> else /tools/bin/install -c -m 644 /sources/glibc-build/stubs.h >>> /usr/include/gnu/stubs-32.h; fi >>> stubs.h unchanged >>> rm -f /sources/glibc-build/stubs.h >>> /sources/glibc-build/elf/sln /sources/glibc-build/elf/symlink.list >>> rm -f /sources/glibc-build/elf/symlink.list >>> test ! -x /sources/glibc-build/elf/ldconfig || LC_ALL=C \ >>> /sources/glibc-build/elf/ldconfig \ >>> /lib /usr/lib >>> LD_SO=ld-linux.so.2 CC="gcc" /usr/bin/perl >>> scripts/test-installation.pl /sources/glibc-build/ >>> >> /tools/lib/gcc/i686-pc-linux-gnu/5.2.0/../../../../i686-pc-linux-gnu/bin/ld: >>> cannot find -lmvec >>> collect2: error: ld returned 1 exit status >>> Execution of gcc failed! >>> The script has found some problems with your installation! >>> Please read the FAQ and the README file and check the following: >>> - Did you change the gcc specs file (necessary after upgrading from >>> Linux libc5)? >>> - Are there any symbolic links of the form libXXX.so to old libraries? >>> Links like libm.so -> libm.so.5 (where libm.so.5 is an old library) >> are wrong, >>> libm.so should point to the newly installed glibc file - and there >> should be >>> only one such link (check e.g. /lib and /usr/lib) >>> You should restart this script from your build directory after you've >>> fixed all problems! >>> Btw. the script doesn't work if you're installing GNU libc not as your >>> primary library! >>> Makefile:108: recipe for target 'install' failed >>> make[2]: *** [install] Error 1 >>> make[2]: Leaving directory '/sources/glibc-2.22' >>> Makefile:12: recipe for target 'install' failed >>> make[1]: *** [install] Error 2 >>> make[1]: Leaving directory '/sources/glibc-build' >>> >> >> Greetings, >> I'm the PiLFS guy from http://www.intestinate.com/pilfs >> I ran into this issue building glibc 2.22 on ARM. >> >>> From what I understand, the mvec code is strictly for x86_64 at this point, >> yet the library name ends up in "glibc-build/soversions.mk" on all >> platforms, which is referenced by "scripts/test-installation.pl" to >> determine what libraries to test-link to. >> >> Because I didn't have the time to figure out how/where mvec ends up in >> soversions.mk, I came up with this small patch: >> >> --- glibc-2.22-orig/scripts/test-installation.pl 2015-08-14 >> 19:06:51.543327102 -0400 >> +++ glibc-2.22/scripts/test-installation.pl 2015-08-14 19:07:51.623396840 >> -0400 >> @@ -111,9 +111,11 @@ >> # - libthread_db since it contains unresolved references >> # - it's just a test NSS module >> # - We don't provide the libgcc so we don't test it >> + # - libmvec is not implemented on ARM >> if ($name ne "nss_ldap" && $name ne "db1" >> && !($name =~/^nss1_/) && $name ne "thread_db" >> - && $name ne "nss_test1" && $name ne "libgcc_s") { >> + && $name ne "nss_test1" && $name ne "libgcc_s" >> + && $name ne "mvec") { >> $link_libs .= " -l$name"; >> $versions{$name} = $version; >> } > > OK, I need to have someone building on a 32-bit system to try adding this to > the beginning of glibc in both Chapter 5 and 6: > > case $(uname -m) in > i?86 ) sed -e 's/libgcc_s"/& \&\& $name ne "mvec"/' \ > -i scripts/test-installation.pl ;; > esac > > Please let me know if that works. > > -- Bruce
There's a recent commit on the glibc 2.22 release branch that fixes this. 9031106ea063f0476bdabf3f5ec22758cdcf987b from Andrew Senkevich on Wed Aug 19. -Charles -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
