Mike Frysinger schrieb: > On Monday 19 October 2009 16:59:55 Thomas Sachau wrote: >> Mike Frysinger schrieb: >>> the majority of the time, the compiler driver (i.e. `gcc`) should be used >>> for linking. very few packages should invoke the linker directly. that >>> is why currently the toolchain-func.eclass has tc-getLD return `ld` -- a >>> few packages need it, but not most. if we're going to be forcing the >>> setting of the LD env var all the time, then it needs to default to >>> ${CC}. packages that need funky behavior should still work as they will >>> be calling $(tc-getLD) anyways. >>> >>>>> - the -L paths to system dirs in LDFLAGS should not be there -- the >>>>> toolchain can handle these just fine >>>> Last time i tried without, some packages failed to compile, will test it >>>> again to check, if its still needed >>> if things are failing, then we should look at gcc/binutils to make sure >>> they use the right default search paths when given -m32/-m64 >> This is an example from configure failure with ABI=x86 for cvs-1.12.12-r6 >> >> last lines from configure: >> >> checking for ssh... ssh >> checking for vim... /bin/nano >> checking for temporary directory... /tmp >> checking security/pam_appl.h usability... yes >> checking security/pam_appl.h presence... yes >> checking for security/pam_appl.h... yes >> checking for pam_start in -lpam... no >> configure: error: Could not find PAM libraries but the headers exist. >> Give the --disable-pam option to compile without PAM support (or fix >> your broken configuration) >> >> !!! Please attach the following file when seeking support: >> !!! /var/tmp/portage/dev-util/cvs-1.12.12-r6/work/cvs-1.12.12/config.log >> * ERROR: dev-util/cvs-1.12.12-r6 failed: >> * econf failed >> >> relevant lines from config.log: >> >> configure:38697: checking for pam_start in -lpam >> configure:38727: x86_64-pc-linux-gnu-gcc -o conftest -march=nocona -O2 >> -pipe -m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib -march=nocona >> -O2 -pipe -Wl,--as-needed conftest.c -lpam -lnsl -lz >&5 >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam >> ic.o): In function `_pam_dlerror': >> (.text+0x1f): undefined reference to `dlerror' >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam >> ic.o): In function `_pam_dlclose': >> (.text+0x5f): undefined reference to `dlclose' >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam >> ic.o): In function `_pam_dlsym': >> (.text+0xa6): undefined reference to `dlsym' >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/../../../../lib32/libpam.a(pam_dynam >> ic.o): In function `_pam_dlopen': >> (.text+0xf2): undefined reference to `dlopen' >> collect2: ld returned 1 exit status >> configure:38733: $? = 1 >> >> If you need some more lines or complete build.log/config.log, feel free to >> tell me and i will send them directly. > > please open a bug about this for the toolchain guys. i dont know when i'll > get to researching this. > -mike
Seems like it was some temporary issue, cannot reproduce it now, so ignore it for now. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature