[OE-core] [PATCH 1/3] distutils-common-base.bbclass: Prepend STAGING_LIBDIR to linker library search path.

[Khem Raj]

On (18/04/11 07:57), Richard Purdie wrote:
> On Mon, 2011-04-18 at 07:54 +0200, Martin Jansa wrote:
> > On Thu, Mar 31, 2011 at 03:26:39PM +0100, Richard Purdie wrote:
> > > On Thu, 2011-03-31 at 12:40 +0200, Martin Jansa wrote:
> > > > * This was done generically in bitbake.conf this should be done on
> > > >   demand and distutils based recipes seem to need it. So we define it
> > > >   here.
> > > > * imported from OE 629ae87eadeec1068c3778e14488b549029adffb
> > > > 
> > > > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > > > ---
> > > >  meta/classes/distutils-common-base.bbclass |    2 ++
> > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/meta/classes/distutils-common-base.bbclass b/meta/classes/distutils-common-base.bbclass
> > > > index f66a5cd..b6caf24 100644
> > > > --- a/meta/classes/distutils-common-base.bbclass
> > > > +++ b/meta/classes/distutils-common-base.bbclass
> > > > @@ -4,6 +4,8 @@ EXTRA_OEMAKE = ""
> > > >  
> > > >  export STAGING_INCDIR
> > > >  export STAGING_LIBDIR
> > > > +# libtool 2.4 does not export with LDFLAGS but distutils need it
> > > > +LDFLAGS_prepend = "-L${STAGING_LIBDIR} "
> > > 
> > > This should not be needed, the linker itself should automatically look
> > > in that path at link time. What problem are you seeing?
> > 
> > sorry for delay, my previous reply was refused by mailman at Mon, 04 Apr 2011
> > with "The message's content type was not explicitly allowed", maybe PGP
> > sign is not allowed? ;/.
> > 
> > 
> > when building any python extra module ie python-numeric I get error like
> > this
> > 
> > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types -fPIC -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/OE/shr-core/tmp/sysroots/arm-oe-linux-gnueabi/usr/include/python2.6 -I/OE/shr-core/tmp/sysroots/nokia900/usr/include/python2.6 -c Src/ufuncobject.c -o build/temp.linux-x86_64-2.6/Src/ufuncobject.o
> > | arm-oe-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mthumb-interwork -mno-thumb -D__SOFTFP__ --sysroot=/OE/shr-core/tmp/sysroots/nokia900 -shared -Wl,-O1 -Wl,--hash-style=gnu -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -g -feliminate-unused-debug-types build/temp.linux-x86_64-2.6/Src/_numpymodule.o build/temp.linux-x86_64-2.6/Src/arrayobject.o build/temp.linux-x86_64-2.6/Src/ufuncobject.o -L/usr/lib -lpython2.6 -o build/lib.linux-x86_64-2.6/_numpy.so
> > | /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ldERROR: Function 'do_compile' failed (see /OE/shr-core/tmp/work/armv7a-oe-linux-gnueabi/python-numeric-24.2-ml1/temp/log.do_compile.16227 for further information)
> > | : warning: library search path "/usr/lib" is unsafe for cross-compilation
> > | /OE/shr-core/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.5.3/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
> > | /usr/lib/libc.a: could not read symbols: File format not recognized
> > | collect2: ld returned 1 exit status
> > | error: command 'arm-oe-linux-gnueabi-gcc' failed with exit status 1
> > | FATAL: python setup.py build_ext execution failed.
> > NOTE: package python-numeric-24.2-ml1: task do_compile: Failed
> > ERROR: Task 4075 (/OE/shr-core/meta-shr/recipes-devtools/python/python-numeric_24.2.bb, do_compile) failed with exit code '1'
> > 
> > in oe we had the same problem after switching to libtool 
> > with sysroot support IIRC and this was fix for it 
> > (and it helps with oe-core too)
> 
> This isn't a libtool problem, we've patched that problem out in oe-core
> (and I think in OE-dev too now). In this case something is adding
> "-L/usr/lib" to the compiler arguments and that is the reason things are
> failing. I'd suggesting finding out where that is coming from and fixing
> it at source. Yes, it so happens adding other search paths first masks
> the problem but it is just masking it, its not a proper fix.

Its added by distutils IIRC when I fixed it in oe.dev with this rev
629ae87eadeec1068c3778e14488b549029adffb this would nullify the addition
since we now have staging libdir before it. 

> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
-Khem