[OE-core] [PATCH] gcc-4.8: fix compiling GCC when /usr/lib/libstdc++.so is present

Jonathan Liu net147 at gmail.com
Mon Jul 22 14:16:33 UTC 2013


On 22/07/2013 11:56 PM, Jonathan Liu wrote:
> On 22/07/2013 2:12 AM, Khem Raj wrote:
>> On Jul 21, 2013, at 3:07 AM, Jonathan Liu <net147 at gmail.com> wrote:
>>
>>> libtool is picking up libstdc++.so from /usr/lib when trying to link
>>> libasan due to libstdc++.la containing libdir="/usr/lib". If compiling
>> Can you also see if this change works on target and SDK environments ?
> I have build the Yocto Build Appliance (qemux86_64) successfully using 
> poky master 31e6eee860b5f9f4ac9ef0889bcff5648de6e3f9 with this patch.
> Also, I have built gcc (for qemux86) successfully from the Yocto Build 
> Appliance (qemux86_64) by manually cloning poky master 
> 31e6eee860b5f9f4ac9ef0889bcff5648de6e3f9 with this patch and building 
> GCC 4.8.1 through Hob (usually the build appliance uses an older git 
> clone of poky that uses GCC 4.7).
> Interestingly the build appliance has /usr/lib/libstdc++.so present so 
> perhaps this libasan linking issue also affects the build appliance.
Confirmed. Building GCC 4.8.1 for qemux86 inside qemux86_64 Yocto Build 
Appliance fails with "/usr/lib/libstdc++.so: could not read symbols: 
File in wrong format" without this patch.

>
> The patch only modifies the libtool (2.2) script included with GCC 
> sources used for building GCC and not the libtool (2.4) that is used 
> elsewhere so its effect should only be limited to building GCC.
> I am not sure how to test this change in SDK environment. Could you 
> elaborate?
>
> Regards,
> Jonathan
>>
>>> for x86 and the host has 64-bit /usr/lib/libstdc++.so, the compilation
>>> fails linking libasan with:
>>> /usr/lib/libstdc++.so: could not read symbols: File in wrong format
>>>
>>> To resolve this, patch libtool to look for the library in the path the
>>> .la is contained in rather than use the libdir which usually points to
>>> a host path.
>>>
>>> [YOCTO #4879]
>>>
>>> Signed-off-by: Jonathan Liu <net147 at gmail.com>
>>> ---
>>> meta/recipes-devtools/gcc/gcc-4.8.inc                 |  1 +
>>> .../gcc/gcc-4.8/0041-libtool-avoid-libdir.patch       | 19 
>>> +++++++++++++++++++
>>> 2 files changed, 20 insertions(+)
>>> create mode 100644 
>>> meta/recipes-devtools/gcc/gcc-4.8/0041-libtool-avoid-libdir.patch
>>>
>>> diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc 
>>> b/meta/recipes-devtools/gcc/gcc-4.8.inc
>>> index dafa241..42355f2 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-4.8.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-4.8.inc
>>> @@ -70,6 +70,7 @@ SRC_URI = 
>>> "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \
>>>        file://0038-gcc-4.8-build-args.patch \
>>>        file://0039-gcc-4.8-PR57717.patch \
>>>        file://0040-fix-g++-sysroot.patch \
>>> +       file://0041-libtool-avoid-libdir.patch \
>>>       "
>>> SRC_URI[md5sum] = "3b2386c114cd74185aa3754b58a79304"
>>> SRC_URI[sha256sum] = 
>>> "545b44be3ad9f2c4e90e6880f5c9d4f0a8f0e5f67e1ffb0d45da9fa01bb05813"
>>> diff --git 
>>> a/meta/recipes-devtools/gcc/gcc-4.8/0041-libtool-avoid-libdir.patch 
>>> b/meta/recipes-devtools/gcc/gcc-4.8/0041-libtool-avoid-libdir.patch
>>> new file mode 100644
>>> index 0000000..2dd9610
>>> --- /dev/null
>>> +++ b/meta/recipes-devtools/gcc/gcc-4.8/0041-libtool-avoid-libdir.patch
>>> @@ -0,0 +1,19 @@
>>> +Avoid using libdir from .la which usually points to a host path
>>> +
>>> +Upstream-Status: Inappropriate [embedded specific]
>>> +Signed-off-by: Jonathan Liu <net147 at gmail.com>
>>> +
>>> +diff --git a/ltmain.sh b/ltmain.sh
>>> +index a03433f..1902a90 100644
>>> +--- a/ltmain.sh
>>> ++++ b/ltmain.sh
>>> +@@ -5628,6 +5628,9 @@ func_mode_link ()
>>> +         absdir="$abs_ladir"
>>> +         libdir="$abs_ladir"
>>> +       else
>>> ++        # Instead of using libdir from .la which usually points to 
>>> a host path,
>>> ++        # use the path the .la is contained in.
>>> ++        libdir="$abs_ladir"
>>> +         dir="$libdir"
>>> +         absdir="$libdir"
>>> +       fi
>>> -- 
>>> 1.8.3.2
>>>
>




More information about the Openembedded-core mailing list