x86_64-pc-linux-gnu-gcc -O2 -pipe -fomit-frame-pointer -Wunused -Wall -o modprobe modprobe.o zlibsupport.o -Wl,-Bstatic -lz -Wl,-Bdynamic /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.5/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.5/../../../../lib/libz.a(gzio.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.5/../../../../lib/libz.a: could not read symbols: Bad value collect2: ld returned 1 exit status Reproducible: Always Steps to Reproduce: 1. emerge module-init-tools Actual Results: Failure as in Details above. Expected Results: Successful emerge
I managed to resolve the issue by recompiling zlib as it seems to be hanging on libz.a Here is my CFlags parameters: CFLAGS="-O3 -march=k8 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops
I changed the CFLAGS to match Karim Ben Ayed's suggestion, and attempted to 'emerge zlib' but got no joy from the excercise. Should I have used a different method to make zlib? Following is the complete output (because it's mercifully short): # emerge zlib Calculating dependencies ...done! >>> emerge (1 of 1) sys-libs/zlib-1.2.2 to / >>> md5 src_uri ;-) zlib-1.2.2.tar.bz2 >>> Unpacking source... >>> Unpacking zlib-1.2.2.tar.bz2 to /var/tmp/portage/zlib-1.2.2/work * Applying zlib-1.2.1-glibc.patch ... [ ok ] * Applying zlib-1.2.1-build-fPIC.patch ... [ ok ] * Applying zlib-1.2.2-mapfile.patch ... [ ok ] * Applying zlib-1.2.1-configure.patch ... [ ok ] * Applying zlib-1.2.1-fPIC.patch ... [ ok ] >>> Source unpacked. Checking for gcc... Checking for shared library support... No shared library support; try without defining CC and CFLAGS Building static library libz.a version 1.2.2 with cc. Checking for unistd.h... No. Checking whether to use vs[n]printf() or s[n]printf()... using s[n]printf() Checking for snprintf() in stdio.h... No. WARNING: snprintf() not found, falling back to sprintf(). zlib can build but will be open to possible buffer-overflow security vulnerabilities. Checking for return value of sprintf()... No. WARNING: apparently sprintf() does not return a value. zlib can build but will be open to possible string-format security vulnerabilities. Checking for errno.h... No. Checking for mmap support... No. cc -O3 -march=k8 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -DNO_snprintf -DHAS_sprintf_void -DNO_ERRNO_H -c -o example.o example.c cc -O3 -march=k8 -ffast-math -funroll-all-loops -funit-at-a-time -fpeel-loops -ftracer -funswitch-loops -DNO_snprintf -DHAS_sprintf_void -DNO_ERRNO_H -c -o adler32.o adler32.c cc1: error: unrecognized option `-funit-at-a-time' cc1: error: unrecognized option `-fpeel-loops' cc1: error: unrecognized option `-funswitch-loops' cc1: error: bad value (k8) for -march= switch cc1: error: bad value (k8) for -mcpu= switch make: *** [adler32.o] Error 1 make: *** Waiting for unfinished jobs.... cc1: error: unrecognized option `-funit-at-a-time' cc1: error: unrecognized option `-fpeel-loops' cc1: error: unrecognized option `-funswitch-loops' cc1: error: bad value (k8) for -march= switch cc1: error: bad value (k8) for -mcpu= switch make: *** [example.o] Error 1 !!! ERROR: sys-libs/zlib-1.2.2 failed.
Our zlib.so is in /lib vs /usr/lib so it should be safe for us to link with just -lz - By not linking with -Wl,-Bstatic -lz -Wl,-Bsynamic we save a few bytes on the final linked elf executable binary sizes. This also fixes text relocations that were showing up in this package. Please test module-init-tools-3.1-r1 and comment here if it solves your problem.
no feed back and module-init-tools-3.1-r1 works fine for me
