Build GCC QA Issue: with objc: No GNU_HASH in the elf binary: '/home/oe/build/tmp/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/objc/usr/lib/libobjc.so.2.0.0'

Build GCC QA Issue: with objc: No GNU_HASH in the elf binary: '/home/oe/build/tmp/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/objc/usr/lib/libobjc.so.2.0.0'

[Jay Snyder]

ERROR: QA Issue with gcc: non -dev package contains symlink .so: gcc 
path 
'/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/gcc/usr/lib/gcc/i686-angstrom-linux/4.3.3/libgcc_s.so'                                                                                                                                                            

ERROR: QA Issue with objc: No GNU_HASH in the elf binary: 
'/home/oe/build/tmp/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/objc/usr/lib/libobjc.so.2.0.0'       

ERROR: QA run found fatal errors. Please consider fixing them.     

I get the GNU_HASH problem with a lot of packages, and quite frankly, it 
is really getting annoying.   My project deadline is quickly 
approaching, and I need a compete system, even if it doesn't have some 
of this security stuff in it (which, is what I assume the HASH stuff is 
for).

Is there any way to configure OE to ingore the QA stuff?     The 
GNU_HASH is not required for a working executable is it?

In this particular case, I'm trying to build a compiler to run natively 
on my target, so I can build some packages that have proved to be real 
tough to cross compile.

I can't be the first one out there to try this?    Has anyone else had 
this problem?

Was this GNU_HASH stuff added somewhere along the way, because it seems 
an aweful lot of packages are broken by this?


Thanks,
Jay

Re: Build GCC QA Issue: with objc: No GNU_HASH in the elf binary: '/home/oe/build/tmp/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/objc/usr/lib/libobjc.so.2.0.0'

[Holger Hans Peter Freyther]

On Monday 22 February 2010 20:11:28 Jay Snyder wrote:

> Is there any way to configure OE to ingore the QA stuff?     The
> GNU_HASH is not required for a working executable is it?


The most easy way to turn it off is to not build with GNU HASH style, This can 
be made by not using "--hash-style=SOMETHING" in the LDFLAGS.

The GNU HASH is not a security mechanism but a dynamic linker optimization to 
be able to resolve symbols faster.

It was added later as the feature is not that old. Everything I do build is 
building fine, so in case you see an "awful" lot of breakage it would be nice 
if you could clarify this.

z.

Re: Build GCC QA Issue: with objc: No GNU_HASH in the elf binary: '/home/oe/build/tmp/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/objc/usr/lib/libobjc.so.2.0.0'

[majo huber]

try the following:
TARGET_CC_ARCH += "${LDFLAGS}"
This should resolve your problems if you build your executable from
within your OE buildsystem.
In very rare cases (e.g. when you build some programs outside of OE
but use OE to package all) it could be useful to use the following:
INSANE_SKIP_objc = "True"
AFAIK that sould not be commonly used, but it worked for me.

majo

2010/2/22 Jay Snyder <jay.snyder@tycoelectronics.com>:
> ERROR: QA Issue with gcc: non -dev package contains symlink .so: gcc path
> '/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/gcc/usr/lib/gcc/i686-angstrom-linux/4.3.3/libgcc_s.so'
>
>
>
> ERROR: QA Issue with objc: No GNU_HASH in the elf binary:
> '/home/oe/build/tmp/work/i686-angstrom-linux/gcc-4.3.3-r10.1/packages-split/objc/usr/lib/libobjc.so.2.0.0'
>
> ERROR: QA run found fatal errors. Please consider fixing them.
> I get the GNU_HASH problem with a lot of packages, and quite frankly, it is
> really getting annoying.   My project deadline is quickly approaching, and I
> need a compete system, even if it doesn't have some of this security stuff
> in it (which, is what I assume the HASH stuff is for).
>
> Is there any way to configure OE to ingore the QA stuff?     The GNU_HASH is
> not required for a working executable is it?
>
> In this particular case, I'm trying to build a compiler to run natively on
> my target, so I can build some packages that have proved to be real tough to
> cross compile.
>
> I can't be the first one out there to try this?    Has anyone else had this
> problem?
>
> Was this GNU_HASH stuff added somewhere along the way, because it seems an
> aweful lot of packages are broken by this?
>
>
> Thanks,
> Jay
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>