Sorry, guys, wrong sender address - resending to include the mailinglist
On 15 Aug 2011 17:18, "Niels de Vos" <niels@xxxxxxxxxxxx> wrote:
> On 15 Aug 2011 15:00, "Andrew Haley" <aph@xxxxxxxxxx> wrote:
>>
>> On 08/15/2011 02:49 PM, Gordan Bobic wrote:
>> > On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph@xxxxxxxxxx>
>> > wrote:
>> >> On 08/15/2011 11:46 AM, Gordan Bobic wrote:
>> >>> On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph@xxxxxxxxxx>
>> >>> wrote:
>> >>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
>> >>>>> On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph@xxxxxxxxxx>
>> >>>>> wrote:
>> >>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
>> >>>>>>>>> On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
>> >>>>>>>>> <aph@xxxxxxxxxx>
>> >>>>>>>>> wrote:
>> >>>>>>>>>> On 08/05/2011 09:07 PM, Gordan Bobic wrote:
>> >>>>>>>>>>> Thanks for pointing out, it does look like the same bug. So
>> >>>>>>>>>>> what's
>> >>>>>>>>>>> the
>> >>>>>>>>>>> fix/workaround?
>> >>>>>>>>>>>
>> >>>>>>>>>>> On 08/05/2011 08:59 PM, Niels de Vos wrote:
>> >>>>>>>>>>>> On 5 Aug 2011 19:15, "Gordan Bobic" <gordan@xxxxxxxxxx
>> >>>>>>>>>>>> <mailto:gordan@xxxxxxxxxx>> wrote:
>> >>>>>>>>>>>> >
>> >>>>>>>>>>>> > How does one pick the correct "ports" part of glibc for
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>> correct core?
>> >>>>>>>>>>>> >
>> >>>>>>>>>>>> > I tried to build the RHEL6 glibc with the F13 ports tar
>> >>>>>>>>>>>> ball,
>> >>>>>>>>>>>> but the
>> >>>>>>>>>>>> > build eventually fails:
>> >>>>>>>>>>>> >
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_eh.a(unwind-arm.o):
>> >>>>>>>>>>>> > In function `__gnu_Unwind_Backtrace':
>> >>>>>>>>>>>> > (.text+0x8b8): undefined reference to
>> >>>>>>>>>>>> `__stack_chk_guard'
>> >>>>>>>>>>>> > collect2: ld returned 1 exit status
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Looks very much like the error in
>> >>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=726495
>> >>>>>>>>>>
>> >>>>>>>>>> What is it linking against? __stack_chk_guard should be
>> >>>>>>>>>> defined
>> >>>>>>>>>> in
>> >>>>>>>>>> libc.a.
>> >>>>>>>
>> >>>>>>> What I would really like to know is what fix the bugzilla
>> >>>>>>> ticket
>> >>>>>>> above
>> >>>>>>> refers to. The last response from Andrew reads:
>> >>>>>>> "I suspect this is just another manifestation of the bug, now
>> >>>>>>> fixed,
>> >>>>>>> that causes
>> >>>>>>> gcj programs not to link, I certainly had no such problem when
>> >>>>>>> I
>> >>>>>>> built
>> >>>>>>> libc
>> >>>>>>> yesterday."
>> >>>>>>>
>> >>>>>>> There's no reference to another bug. Can anyone point me in the
>> >>>>>>> direction of the relevant bugzilla ticket that fixes the said
>> >>>>>>> gcj
>> >>>>>>> linking issue? I just searched on RH bugzilla and couldn't find
>> >>>>>>> anything
>> >>>>>>> of relevance.
>> >>>>>>
>> >>>>>> Sorry, I gave up on F13 when it became EOL and moved to F15. No
>> >>>>>> more
>> >>>>>> bugs were being accepted.
>> >>>>>>
>> >>>>>> Is /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/libgcc_s.so
>> >>>>>> (or
>> >>>>>> whatever)
>> >>>>>> a symlink or a text file on your system?
>> >>>>>>
>> >>>>>> It should look like this:
>> >>>>>>
>> >>>>>> /* GNU ld script
>> >>>>>> Use the shared library, but some functions are only in
>> >>>>>> the static library. */
>> >>>>>> GROUP ( /lib/libgcc_s.so.1 libgcc.a )
>> >>>>>
>> >>>>> It's a symlink to libgcc_s.so.1. Should it be a text file??
>> >>>>
>> >>>> Yes. This is a bug in the Fedora gcc specfile. Upstream gcc is
>> >>>> correct.
>> >>>
>> >>> Got a link to the relevant spec file patch handy?
>> >>
>> >> I don't think this is the cause of your bug, but I've attached my
>> >> specfile.
>> >
>> > Just to make sure we're talking about the same bug here, are you
>> > referring to this one:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=726495
>> >
>> > Is that the bug that you are saying ISN'T related to the libgcc_s.so
>> > symlink vs. text file issue?
>>
>> Yes. Probably.
>
> I am pretty sure that I replaced the symlink by a linker script to see if
> that gave any improvements. For all I remember and have logged in the bugs,
> the result was the same build error. Not using -static-libgcc or adding
> libc.a for linking seems a workaround that makes building succeed.
>
> This may well caused by unwind-arm.o referring to __stack_chk_guard. If that
> is fixed in an upstream gcc, we would need to see if we can backport that to
> Fedora 14. If that works:
> 1. Update gcc
> 2. Rebuild F-14 glibc
> 3. Keep closer to primary architectures
>
> Any ideas/corrections/references welcome :)
>
>> By the way, you don't have to build gcc to be sure. Extract unwind-arm.o
>> from libgcc_eh.a, run nm on it, and see if there is a reference to
>> __stack_chk_guard
>>
>> Andrew.
>> _______________________________________________
>> arm mailing list
>> arm@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/arm
> On 15 Aug 2011 15:00, "Andrew Haley" <aph@xxxxxxxxxx> wrote:
>>
>> On 08/15/2011 02:49 PM, Gordan Bobic wrote:
>> > On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph@xxxxxxxxxx>
>> > wrote:
>> >> On 08/15/2011 11:46 AM, Gordan Bobic wrote:
>> >>> On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph@xxxxxxxxxx>
>> >>> wrote:
>> >>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
>> >>>>> On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph@xxxxxxxxxx>
>> >>>>> wrote:
>> >>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
>> >>>>>>>>> On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
>> >>>>>>>>> <aph@xxxxxxxxxx>
>> >>>>>>>>> wrote:
>> >>>>>>>>>> On 08/05/2011 09:07 PM, Gordan Bobic wrote:
>> >>>>>>>>>>> Thanks for pointing out, it does look like the same bug. So
>> >>>>>>>>>>> what's
>> >>>>>>>>>>> the
>> >>>>>>>>>>> fix/workaround?
>> >>>>>>>>>>>
>> >>>>>>>>>>> On 08/05/2011 08:59 PM, Niels de Vos wrote:
>> >>>>>>>>>>>> On 5 Aug 2011 19:15, "Gordan Bobic" <gordan@xxxxxxxxxx
>> >>>>>>>>>>>> <mailto:gordan@xxxxxxxxxx>> wrote:
>> >>>>>>>>>>>> >
>> >>>>>>>>>>>> > How does one pick the correct "ports" part of glibc for
>> >>>>>>>>>>>> the
>> >>>>>>>>>>>> correct core?
>> >>>>>>>>>>>> >
>> >>>>>>>>>>>> > I tried to build the RHEL6 glibc with the F13 ports tar
>> >>>>>>>>>>>> ball,
>> >>>>>>>>>>>> but the
>> >>>>>>>>>>>> > build eventually fails:
>> >>>>>>>>>>>> >
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_eh.a(unwind-arm.o):
>> >>>>>>>>>>>> > In function `__gnu_Unwind_Backtrace':
>> >>>>>>>>>>>> > (.text+0x8b8): undefined reference to
>> >>>>>>>>>>>> `__stack_chk_guard'
>> >>>>>>>>>>>> > collect2: ld returned 1 exit status
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Looks very much like the error in
>> >>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=726495
>> >>>>>>>>>>
>> >>>>>>>>>> What is it linking against? __stack_chk_guard should be
>> >>>>>>>>>> defined
>> >>>>>>>>>> in
>> >>>>>>>>>> libc.a.
>> >>>>>>>
>> >>>>>>> What I would really like to know is what fix the bugzilla
>> >>>>>>> ticket
>> >>>>>>> above
>> >>>>>>> refers to. The last response from Andrew reads:
>> >>>>>>> "I suspect this is just another manifestation of the bug, now
>> >>>>>>> fixed,
>> >>>>>>> that causes
>> >>>>>>> gcj programs not to link, I certainly had no such problem when
>> >>>>>>> I
>> >>>>>>> built
>> >>>>>>> libc
>> >>>>>>> yesterday."
>> >>>>>>>
>> >>>>>>> There's no reference to another bug. Can anyone point me in the
>> >>>>>>> direction of the relevant bugzilla ticket that fixes the said
>> >>>>>>> gcj
>> >>>>>>> linking issue? I just searched on RH bugzilla and couldn't find
>> >>>>>>> anything
>> >>>>>>> of relevance.
>> >>>>>>
>> >>>>>> Sorry, I gave up on F13 when it became EOL and moved to F15. No
>> >>>>>> more
>> >>>>>> bugs were being accepted.
>> >>>>>>
>> >>>>>> Is /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/libgcc_s.so
>> >>>>>> (or
>> >>>>>> whatever)
>> >>>>>> a symlink or a text file on your system?
>> >>>>>>
>> >>>>>> It should look like this:
>> >>>>>>
>> >>>>>> /* GNU ld script
>> >>>>>> Use the shared library, but some functions are only in
>> >>>>>> the static library. */
>> >>>>>> GROUP ( /lib/libgcc_s.so.1 libgcc.a )
>> >>>>>
>> >>>>> It's a symlink to libgcc_s.so.1. Should it be a text file??
>> >>>>
>> >>>> Yes. This is a bug in the Fedora gcc specfile. Upstream gcc is
>> >>>> correct.
>> >>>
>> >>> Got a link to the relevant spec file patch handy?
>> >>
>> >> I don't think this is the cause of your bug, but I've attached my
>> >> specfile.
>> >
>> > Just to make sure we're talking about the same bug here, are you
>> > referring to this one:
>> > https://bugzilla.redhat.com/show_bug.cgi?id=726495
>> >
>> > Is that the bug that you are saying ISN'T related to the libgcc_s.so
>> > symlink vs. text file issue?
>>
>> Yes. Probably.
>
> I am pretty sure that I replaced the symlink by a linker script to see if
> that gave any improvements. For all I remember and have logged in the bugs,
> the result was the same build error. Not using -static-libgcc or adding
> libc.a for linking seems a workaround that makes building succeed.
>
> This may well caused by unwind-arm.o referring to __stack_chk_guard. If that
> is fixed in an upstream gcc, we would need to see if we can backport that to
> Fedora 14. If that works:
> 1. Update gcc
> 2. Rebuild F-14 glibc
> 3. Keep closer to primary architectures
>
> Any ideas/corrections/references welcome :)
>
>> By the way, you don't have to build gcc to be sure. Extract unwind-arm.o
>> from libgcc_eh.a, run nm on it, and see if there is a reference to
>> __stack_chk_guard
>>
>> Andrew.
>> _______________________________________________
>> arm mailing list
>> arm@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
