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

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to