gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Sledz, Steffen]

gcc_4.2.4.bb reports these errors for a few days. Can someone please have a look at it.

ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc/usr/bin/arm-angstrom-linux-gnueabi-gcc'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/collect2'
ERROR: QA Issue: non -dev package contains symlink .so: gcc path '/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.2.4/libgcc_s.so'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/g++/usr/bin/arm-angstrom-linux-gnueabi-g++'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/g++/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/cc1plus'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/cpp/usr/bin/arm-angstrom-linux-gnueabi-cpp'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/cpp/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/cc1'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gfortran/usr/bin/arm-angstrom-linux-gnueabi-gfortran'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gfortran/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/f951'
ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcov/usr/bin/arm-angstrom-linux-gnueabi-gcov'
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function
ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function
ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function
ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
ERROR: Printing the environment of the function
ERROR: Build of /opt/openembedded/recipes/gcc/gcc_4.2.4.bb do_package failed
ERROR: Task 1281 (/opt/openembedded/recipes/gcc/gcc_4.2.4.bb, do_package) failed
ERROR: '/opt/openembedded/recipes/gcc/gcc_4.2.4.bb' failed

Thx,
Steffen

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Sledz, Steffen]

Ping.

At the moment we are not able to make a build out of the .dev tree. :(

> -----Original Message-----
> From: openembedded-devel-bounces@lists.openembedded.org 
> [mailto:openembedded-devel-bounces@lists.openembedded.org] On 
> Behalf Of Sledz, Steffen
> Sent: Friday, April 24, 2009 1:55 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: [oe] gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary
> 
> gcc_4.2.4.bb reports these errors for a few days. Can someone 
> please have a look at it.
> 
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/gcc/usr/bin/arm-angstrom-linux-gnueabi-gcc'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/gcc/usr/libexec/gcc/arm-angstrom-linux-gnueab
> i/4.2.4/collect2'
> ERROR: QA Issue: non -dev package contains symlink .so: gcc 
> path 
> '/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc
> /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.2.4/libgcc_s.so'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/g++/usr/bin/arm-angstrom-linux-gnueabi-g++'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/g++/usr/libexec/gcc/arm-angstrom-linux-gnueab
> i/4.2.4/cc1plus'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/cpp/usr/bin/arm-angstrom-linux-gnueabi-cpp'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/cpp/usr/libexec/gcc/arm-angstrom-linux-gnueab
> i/4.2.4/cc1'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/gfortran/usr/bin/arm-angstrom-linux-gnueabi-gfortran'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/gfortran/usr/libexec/gcc/arm-angstrom-linux-g
> nueabi/4.2.4/f951'
> ERROR: QA Issue: No GNU_HASH in the elf binary: 
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
> 4.2.4-r3/install/gcov/usr/bin/arm-angstrom-linux-gnueabi-gcov'
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
> ERROR: Printing the environment of the function
> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
> ERROR: Printing the environment of the function
> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
> ERROR: Printing the environment of the function
> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
> ERROR: Printing the environment of the function
> ERROR: Build of /opt/openembedded/recipes/gcc/gcc_4.2.4.bb 
> do_package failed
> ERROR: Task 1281 (/opt/openembedded/recipes/gcc/gcc_4.2.4.bb, 
> do_package) failed
> ERROR: '/opt/openembedded/recipes/gcc/gcc_4.2.4.bb' failed
> 
> Thx,
> Steffen
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 4102 bytes --]

Sledz, Steffen wrote:
> Ping.
> 
> At the moment we are not able to make a build out of the .dev tree. :(

For what machine and distro?

Philip




> 
>> -----Original Message-----
>> From: openembedded-devel-bounces@lists.openembedded.org 
>> [mailto:openembedded-devel-bounces@lists.openembedded.org] On 
>> Behalf Of Sledz, Steffen
>> Sent: Friday, April 24, 2009 1:55 PM
>> To: openembedded-devel@lists.openembedded.org
>> Subject: [oe] gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary
>>
>> gcc_4.2.4.bb reports these errors for a few days. Can someone 
>> please have a look at it.
>>
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/gcc/usr/bin/arm-angstrom-linux-gnueabi-gcc'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/gcc/usr/libexec/gcc/arm-angstrom-linux-gnueab
>> i/4.2.4/collect2'
>> ERROR: QA Issue: non -dev package contains symlink .so: gcc 
>> path 
>> '/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc
>> /usr/lib/gcc/arm-angstrom-linux-gnueabi/4.2.4/libgcc_s.so'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/g++/usr/bin/arm-angstrom-linux-gnueabi-g++'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/g++/usr/libexec/gcc/arm-angstrom-linux-gnueab
>> i/4.2.4/cc1plus'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/cpp/usr/bin/arm-angstrom-linux-gnueabi-cpp'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/cpp/usr/libexec/gcc/arm-angstrom-linux-gnueab
>> i/4.2.4/cc1'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/gfortran/usr/bin/arm-angstrom-linux-gnueabi-gfortran'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/gfortran/usr/libexec/gcc/arm-angstrom-linux-g
>> nueabi/4.2.4/f951'
>> ERROR: QA Issue: No GNU_HASH in the elf binary: 
>> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-
>> 4.2.4-r3/install/gcov/usr/bin/arm-angstrom-linux-gnueabi-gcov'
>> ERROR: QA run found fatal errors. Please consider fixing them.
>> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
>> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
>> ERROR: Printing the environment of the function
>> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
>> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
>> ERROR: Printing the environment of the function
>> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
>> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
>> ERROR: Printing the environment of the function
>> ERROR: Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
>> ERROR: Exception:<type 'exceptions.SystemExit'> Message:1
>> ERROR: Printing the environment of the function
>> ERROR: Build of /opt/openembedded/recipes/gcc/gcc_4.2.4.bb 
>> do_package failed
>> ERROR: Task 1281 (/opt/openembedded/recipes/gcc/gcc_4.2.4.bb, 
>> do_package) failed
>> ERROR: '/opt/openembedded/recipes/gcc/gcc_4.2.4.bb' failed
>>
>> Thx,
>> Steffen
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Tom Rini]

On Mon, Apr 27, 2009 at 07:47:52AM -0400, Philip Balister wrote:
> Sledz, Steffen wrote:
>> Ping.
>>
>> At the moment we are not able to make a build out of the .dev tree. :(
>
> For what machine and distro?

Any and all.

-- 
Tom Rini

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Sledz, Steffen]

> > At the moment we are not able to make a build out of the 
> > .dev tree. :(
> 
> For what machine and distro?

hipox and angstrom

But does this problem really depends on them? I thought it's a problem in the gcc-4.2.4 recipe.

Steffen

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Tom Rini]

On Mon, Apr 27, 2009 at 03:37:25PM +0200, Sledz, Steffen wrote:
> > > At the moment we are not able to make a build out of the 
> > > .dev tree. :(
> > 
> > For what machine and distro?
> 
> hipox and angstrom
> 
> But does this problem really depends on them? I thought it's a problem in the gcc-4.2.4 recipe.

It's in all gcc versions, really.

-- 
Tom Rini

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Dmitry Eremin-Solenikov]

Sledz, Steffen wrote:

> gcc_4.2.4.bb reports these errors for a few days. Can someone please
> have a look at it.
> 
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc/usr/bin/arm-angstrom-linux-gnueabi-gcc'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/collect2'
> ERROR: QA Issue: non -dev package contains symlink .so: gcc path
> '/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcc/usr/lib/gcc/arm-angstrom-linux-gnueabi/4.2.4/libgcc_s.so'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/g++/usr/bin/arm-angstrom-linux-gnueabi-g++'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/g++/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/cc1plus'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/cpp/usr/bin/arm-angstrom-linux-gnueabi-cpp'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/cpp/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/cc1'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gfortran/usr/bin/arm-angstrom-linux-gnueabi-gfortran'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gfortran/usr/libexec/gcc/arm-angstrom-linux-gnueabi/4.2.4/f951'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/home/sledz/oe/tmp.1/work/armv5te-angstrom-linux-gnueabi/gcc-4.2.4-r3/install/gcov/usr/bin/arm-angstrom-linux-gnueabi-gcov'
> ERROR: QA run found fatal errors. Please consider fixing them. ERROR:
> Error in executing: /opt/openembedded/recipes/gcc/gcc_4.2.4.bb ERROR:
> Exception:<type 'exceptions.SystemExit'> Message:1 ERROR: Printing the
> environment of the function ERROR: Error in executing:
> /opt/openembedded/recipes/gcc/gcc_4.2.4.bb ERROR: Exception:<type
> 'exceptions.SystemExit'> Message:1 ERROR: Printing the environment of
> the function ERROR: Error in executing:
> /opt/openembedded/recipes/gcc/gcc_4.2.4.bb ERROR: Exception:<type
> 'exceptions.SystemExit'> Message:1 ERROR: Printing the environment of
> the function ERROR: Error in executing:
> /opt/openembedded/recipes/gcc/gcc_4.2.4.bb ERROR: Exception:<type
> 'exceptions.SystemExit'> Message:1 ERROR: Printing the environment of
> the function ERROR: Build of /opt/openembedded/recipes/gcc/gcc_4.2.4.bb
> do_package failed ERROR: Task 1281
> (/opt/openembedded/recipes/gcc/gcc_4.2.4.bb, do_package) failed ERROR:
> '/opt/openembedded/recipes/gcc/gcc_4.2.4.bb' failed
> 

Confirmed here for at91sam9g20-ek and for collie



-- 
With best wishes
Dmitry

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Koen Kooi]

On 27-04-09 15:43, Tom Rini wrote:
> On Mon, Apr 27, 2009 at 03:37:25PM +0200, Sledz, Steffen wrote:
>>>> At the moment we are not able to make a build out of the
>>>> .dev tree. :(
>>>
>>> For what machine and distro?
>>
>> hipox and angstrom
>>
>> But does this problem really depends on them? I thought it's a problem in the gcc-4.2.4 recipe.
>
> It's in all gcc versions, really.

No, it isn't:

NOTE: package gcc-4.3.3-r0: task do_build: completed

Anyway, isn't ldflags.patch supposed to fix missing ldflags?

regards,

Koen

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Tom Rini]

On Mon, Apr 27, 2009 at 04:14:52PM +0200, Koen Kooi wrote:
> On 27-04-09 15:43, Tom Rini wrote:
>> On Mon, Apr 27, 2009 at 03:37:25PM +0200, Sledz, Steffen wrote:
>>>>> At the moment we are not able to make a build out of the
>>>>> .dev tree. :(
>>>>
>>>> For what machine and distro?
>>>
>>> hipox and angstrom
>>>
>>> But does this problem really depends on them? I thought it's a problem in the gcc-4.2.4 recipe.
>>
>> It's in all gcc versions, really.
>
> No, it isn't:
>
> NOTE: package gcc-4.3.3-r0: task do_build: completed

Hmm, I'd swear I saw it fail in 4.3.x too, but OK.

-- 
Tom Rini

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Sledz, Steffen]

> > It's in all gcc versions, really.
> 
> No, it isn't:
> 
> NOTE: package gcc-4.3.3-r0: task do_build: completed

Clean build?

I had the error just there.

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Stanislav Brabec]

Sledz, Steffen wrote:
> > > It's in all gcc versions, really.
> > 
> > No, it isn't:
> > 
> > NOTE: package gcc-4.3.3-r0: task do_build: completed

I can confirm the failure in the default angstrom build for spitz from
the last week. Linking of gcc wrapper and few other utilities reported
the standard GNU_HASH QA error.

Here is a possible fix or work-around. It's tested and it works, but
maybe it is not fully correct.

It may be one of following problems. I did not search deeper which one
is true:
- Ignoring LDFLAGS passed to configure
- LDFLAGS x LDFLAGS_FOR_TARGET clash
- LDFLAGS_FOR_TARGET are not set in cross builds of native gcc compiler
  (i. e. not canadian)

diff --git a/recipes/gcc/gcc-configure-common.inc b/recipes/gcc/gcc-configure-common.inc
index e88cee5..ef42210 100644
--- a/recipes/gcc/gcc-configure-common.inc
+++ b/recipes/gcc/gcc-configure-common.inc
@@ -73,6 +73,7 @@ do_configure () {
 	export CPPFLAGS_FOR_BUILD="${BUILD_CPPFLAGS}"
 	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
 	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
+	export CC="${CC} ${LDFLAGS}"
 	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
 	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
 


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: gcc_4.2.4.bb: QA Issue: No GNU_HASH in the elf binary

[Tom Rini]

On Mon, Apr 27, 2009 at 04:14:52PM +0200, Koen Kooi wrote:
[snip]
> Anyway, isn't ldflags.patch supposed to fix missing ldflags?

Supposed to, but doesn't cover everything.

-- 
Tom Rini

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Sledz, Steffen]

> I can confirm the failure in the default angstrom build for spitz from
> the last week. Linking of gcc wrapper and few other utilities reported
> the standard GNU_HASH QA error.
> 
> Here is a possible fix or work-around. It's tested and it works, but
> maybe it is not fully correct.
> 
> It may be one of following problems. I did not search deeper which one
> is true:
> - Ignoring LDFLAGS passed to configure
> - LDFLAGS x LDFLAGS_FOR_TARGET clash
> - LDFLAGS_FOR_TARGET are not set in cross builds of native 
> gcc compiler
>   (i. e. not canadian)

Fix works for me. But it would be nice if some members of the core team could ack it.

Steffen

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Sledz, Steffen wrote:
>> I can confirm the failure in the default angstrom build for spitz from
>> the last week. Linking of gcc wrapper and few other utilities reported
>> the standard GNU_HASH QA error.
>>
>> Here is a possible fix or work-around. It's tested and it works, but
>> maybe it is not fully correct.
>>
>> It may be one of following problems. I did not search deeper which one
>> is true:
>> - Ignoring LDFLAGS passed to configure
>> - LDFLAGS x LDFLAGS_FOR_TARGET clash
>> - LDFLAGS_FOR_TARGET are not set in cross builds of native 
>> gcc compiler
>>   (i. e. not canadian)
> 
> Fix works for me. But it would be nice if some members of the core team could ack it.

Does anyone see any downside for this patch? Have other people tested 
it? I hate blind acking things.

Philip


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Tom Rini]

On Wed, Apr 29, 2009 at 08:21:15AM -0400, Philip Balister wrote:
> Sledz, Steffen wrote:
>>> I can confirm the failure in the default angstrom build for spitz from
>>> the last week. Linking of gcc wrapper and few other utilities reported
>>> the standard GNU_HASH QA error.
>>>
>>> Here is a possible fix or work-around. It's tested and it works, but
>>> maybe it is not fully correct.
>>>
>>> It may be one of following problems. I did not search deeper which one
>>> is true:
>>> - Ignoring LDFLAGS passed to configure
>>> - LDFLAGS x LDFLAGS_FOR_TARGET clash
>>> - ???LDFLAGS_FOR_TARGET are not set in cross builds of native gcc 
>>> compiler
>>>   (i. e. not canadian)
>>
>> Fix works for me. But it would be nice if some members of the core team could ack it.
>
> Does anyone see any downside for this patch? Have other people tested  
> it? I hate blind acking things.

Khem has a patch for this issue too but wants to test it more.

-- 
Tom Rini

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Stanislav Brabec]

Tom Rini wrote: 
> On Wed, Apr 29, 2009 at 08:21:15AM -0400, Philip Balister wrote:
> > Sledz, Steffen wrote:

> >> Fix works for me. But it would be nice if some members of the core team could ack it.
> >
> > Does anyone see any downside for this patch? Have other people tested  
> > it? I hate blind acking things.
> 
> Khem has a patch for this issue too but wants to test it more.

I just tested another way to fix. It looks like a gcc bug - LDFLAGS nor
LDFLAGS_FOR_TARGET are not used in gcc/Makefile.

diff --git a/recipes/gcc/gcc-configure-common.inc b/recipes/gcc/gcc-configure-common.inc
index e88cee5..9ede6a2 100644
--- a/recipes/gcc/gcc-configure-common.inc
+++ b/recipes/gcc/gcc-configure-common.inc
@@ -73,7 +73,18 @@ do_configure () {
 	export CPPFLAGS_FOR_BUILD="${BUILD_CPPFLAGS}"
 	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
 	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
 	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
+	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl
 	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
 
 	# splice our idea of where the headers live into gcc's world


My previous patch built the whole feed. But I did not test it with
canadian recipes.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Tom Rini]

On Wed, Apr 29, 2009 at 06:26:15PM +0200, Stanislav Brabec wrote:
> Tom Rini wrote: 
> > On Wed, Apr 29, 2009 at 08:21:15AM -0400, Philip Balister wrote:
> > > Sledz, Steffen wrote:
> 
> > >> Fix works for me. But it would be nice if some members of the core team could ack it.
> > >
> > > Does anyone see any downside for this patch? Have other people tested  
> > > it? I hate blind acking things.
> > 
> > Khem has a patch for this issue too but wants to test it more.
> 
> I just tested another way to fix. It looks like a gcc bug - LDFLAGS nor
> LDFLAGS_FOR_TARGET are not used in gcc/Makefile.
> 
> diff --git a/recipes/gcc/gcc-configure-common.inc b/recipes/gcc/gcc-configure-common.inc
> index e88cee5..9ede6a2 100644
> --- a/recipes/gcc/gcc-configure-common.inc
> +++ b/recipes/gcc/gcc-configure-common.inc
> @@ -73,7 +73,18 @@ do_configure () {
>  	export CPPFLAGS_FOR_BUILD="${BUILD_CPPFLAGS}"
>  	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
>  	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
>  	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
> +	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl
>  	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
>  
>  	# splice our idea of where the headers live into gcc's world
> 
> 
> My previous patch built the whole feed. But I did not test it with
> canadian recipes.

I'll pull this in locally, and build everything today.  Just need to
have the buildbot finish the failure on everything first.

-- 
Tom Rini

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Stanislav Brabec]

Tom Rini wrote:
> > +	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl

> I'll pull this in locally, and build everything today.  Just need to
> have the buildbot finish the failure on everything first.

Well, without "if test -f" it will fail for gcc-4.4.0. This one would be
safer for the final commit. Patching each gcc version separately would
be even more safe, but also more work.

Note: gcc-4.4.0 already contains exactly this fix.

diff --git a/recipes/gcc/gcc-configure-common.inc b/recipes/gcc/gcc-configure-common.inc
index e88cee5..f468a6b 100644
--- a/recipes/gcc/gcc-configure-common.inc
+++ b/recipes/gcc/gcc-configure-common.inc
@@ -74,6 +74,9 @@ do_configure () {
 	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
 	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
 	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
+	# gcc before 4.4.0 ignores LDFLAGS:
+	if test -f ${S}/Makefile.in ; then sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ; fi
+	if test -f ${S}/Makefile.tpl ; then sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.tpl ; fi
 	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
 
 	# splice our idea of where the headers live into gcc's world

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Tom Rini]

On Wed, Apr 29, 2009 at 07:32:25PM +0200, Stanislav Brabec wrote:
> Tom Rini wrote:
> > > +	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl
> 
> > I'll pull this in locally, and build everything today.  Just need to
> > have the buildbot finish the failure on everything first.
> 
> Well, without "if test -f" it will fail for gcc-4.4.0. This one would be
> safer for the final commit. Patching each gcc version separately would
> be even more safe, but also more work.

OK, some unpacking and grepping and such done.  4.3.x, 4.4.0 and oddly,
4.0.x are good.  The rest are not.  But, I don't see how the if works,
unless ${S} isn't right in gcc-4.4.0, as all versions have
gcc-$VERSION/Makefile.{in,tpl}.

Regardless, I think the approach we should go with is a fixup, per
gcc-version.inc.  Roughly:

do_configure_prepend() {
	# Make sure we don't ignore ldflags.
	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in
	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.tpl
}

And I'll check if we can drop the incomplete ldflags.patch too.

-- 
Tom Rini

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Tom Rini]

On Wed, Apr 29, 2009 at 01:17:12PM -0700, Tom Rini wrote:
> On Wed, Apr 29, 2009 at 07:32:25PM +0200, Stanislav Brabec wrote:
> > Tom Rini wrote:
> > > > +	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl
> > 
> > > I'll pull this in locally, and build everything today.  Just need to
> > > have the buildbot finish the failure on everything first.
> > 
> > Well, without "if test -f" it will fail for gcc-4.4.0. This one would be
> > safer for the final commit. Patching each gcc version separately would
> > be even more safe, but also more work.
> 
> OK, some unpacking and grepping and such done.  4.3.x, 4.4.0 and oddly,
> 4.0.x are good.  The rest are not.  But, I don't see how the if works,

I take that back.  The 4.0.x ldflags.patch is good.  What I get for
doing a -c patch unstead of -c unpack :)

-- 
Tom Rini

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Tom Rini]

On Wed, Apr 29, 2009 at 06:26:15PM +0200, Stanislav Brabec wrote:
> Tom Rini wrote: 
> > On Wed, Apr 29, 2009 at 08:21:15AM -0400, Philip Balister wrote:
> > > Sledz, Steffen wrote:
> 
> > >> Fix works for me. But it would be nice if some members of the core team could ack it.
> > >
> > > Does anyone see any downside for this patch? Have other people tested  
> > > it? I hate blind acking things.
> > 
> > Khem has a patch for this issue too but wants to test it more.
> 
> I just tested another way to fix. It looks like a gcc bug - LDFLAGS nor
> LDFLAGS_FOR_TARGET are not used in gcc/Makefile.
> 
> diff --git a/recipes/gcc/gcc-configure-common.inc b/recipes/gcc/gcc-configure-common.inc
> index e88cee5..9ede6a2 100644
> --- a/recipes/gcc/gcc-configure-common.inc
> +++ b/recipes/gcc/gcc-configure-common.inc
> @@ -73,7 +73,18 @@ do_configure () {
>  	export CPPFLAGS_FOR_BUILD="${BUILD_CPPFLAGS}"
>  	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
>  	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
>  	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
> +	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl
>  	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
>  
>  	# splice our idea of where the headers live into gcc's world

Based on this, I've got a patch mostly ready to go, tomorrow.  Building
fine for gcc-* are;
- 4.1.1, 4.1.2, 4.2.[234], 4.3.[123] and 4.4.0
I've got some other changes done so that 4.1.0, 4.0.0 and 4.0.2 build or
mostly build.  For 4.1.0 I had to point it at 4.1.1's patches as there's
no 4.1.0 patch directory.  For 4.0.x I've had to pull in the posix
open() fixup from 3.x (and I've renamed and moved to files/) and pass in
--disable-libmudflap.  All of these also won't build on x86_64 so I've
dropped down to a 32bit chroot for these in particular.  I've patched
but haven't tried yet, 3.3.x / 3.4.x.

This also drops the incomplete in many cases and no longer needed
ldflags.patch as well.

The above has distracted me a bit from trying the canadian-sdk stuff but
I will before pushing this.

-- 
Tom Rini

Re: [PATCH] gcc_4.2.4.bb: QA Issue: No GNU_HASH in theelf binary

[Tom Rini]

On Wed, Apr 29, 2009 at 09:45:00AM -0700, Tom Rini wrote:
> On Wed, Apr 29, 2009 at 06:26:15PM +0200, Stanislav Brabec wrote:
> > Tom Rini wrote: 
> > > On Wed, Apr 29, 2009 at 08:21:15AM -0400, Philip Balister wrote:
> > > > Sledz, Steffen wrote:
> > 
> > > >> Fix works for me. But it would be nice if some members of the core team could ack it.
> > > >
> > > > Does anyone see any downside for this patch? Have other people tested  
> > > > it? I hate blind acking things.
> > > 
> > > Khem has a patch for this issue too but wants to test it more.
> > 
> > I just tested another way to fix. It looks like a gcc bug - LDFLAGS nor
> > LDFLAGS_FOR_TARGET are not used in gcc/Makefile.
> > 
> > diff --git a/recipes/gcc/gcc-configure-common.inc b/recipes/gcc/gcc-configure-common.inc
> > index e88cee5..9ede6a2 100644
> > --- a/recipes/gcc/gcc-configure-common.inc
> > +++ b/recipes/gcc/gcc-configure-common.inc
> > @@ -73,7 +73,18 @@ do_configure () {
> >  	export CPPFLAGS_FOR_BUILD="${BUILD_CPPFLAGS}"
> >  	export CXXFLAGS_FOR_BUILD="${BUILD_CXXFLAGS}"
> >  	export LDFLAGS_FOR_BUILD="${BUILD_LDFLAGS}"
> >  	export ARCH_FLAGS_FOR_TARGET="${ARCH_FLAGS_FOR_TARGET}"
> > +	sed -i 's/^LDFLAGS = $/LDFLAGS = @LDFLAGS@/' ${S}/Makefile.in ${S}/Makefile.tpl
> >  	(cd ${S} && gnu-configize) || die "failure running gnu-configize"
> >  
> >  	# splice our idea of where the headers live into gcc's world
> > 
> > 
> > My previous patch built the whole feed. But I did not test it with
> > canadian recipes.
> 
> I'll pull this in locally, and build everything today.  Just need to
> have the buildbot finish the failure on everything first.

OK, tested everything that was building and made some of the older stuff
build, or at least be a bit closer to building.

-- 
Tom Rini