Build Failure on Cygwin
Joel Sherrill
joel@rtems.org
Mon Oct 19 23:03:08 GMT 2020
Following up, I have filed a ticket. GDB does not build native or cross
on Cygwin. Same error both ways.
You have to build with --disable-werror or it fails before it gets that far
when building natively.
I have filed two tickets about this.
--joel
On Mon, Oct 19, 2020 at 2:33 PM Joel Sherrill <joel@rtems.org> wrote:
>
>
> On Mon, Oct 19, 2020 at 12:46 PM Hannes Domani <ssbssa@yahoo.de> wrote:
>
>> Am Montag, 19. Oktober 2020, 19:26:28 MESZ hat Joel Sherrill <
>> joel@rtems.org> Folgendes geschrieben:
>>
>> > Hi
>> >
>> > I am getting a build failure on Cygwin
>> >
>> >
>> /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x5502):
>> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS
>> > init function for thread_local_segv_handler'
>> >
>> /home/jrs007/rtems-cron-6/rtems-source-builder/rtems/build/aarch64-rtems6-gdb-8a6e98c-x86_64-pc-cygwin-1/build/gdb/../../sourceware-mirror-binutils-gdb-8a6e98c/gdb/cp-support.c:1619:(.text+0x551b):
>> > relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS
>> > init function for thread_local_segv_handler'
>> > collect2: error: ld returned 1 exit status
>> >
>> > This is a build targeting RTEMS based on a tarball fetched from
>> > git:(sourceware-mirror-binutils-gdb-8a6e98c). It should correspond to
>> this
>> > recent commit:
>> >
>> > ommit 8a6e98c4a3049d7fb8ffc24b231e8cf3577fd90a
>> > Author: GDB Administrator <gdbadmin@sourceware.org>
>> > Date: Mon Oct 12 00:00:07 2020 +0000
>> >
>> > Automatic date update in version.in
>> >
>> > Any suggestions on how to fix this?
>>
>> Isn't that the same problem you already started a thread about in march?:
>> https://sourceware.org/pipermail/gdb/2020-March/048436.html
>>
>> And it ended with you planning to file a gdb bug.
>>
>
> Yes and I have completely forgotten about that. I sent that about a week
> after
> I started working from home. Apparently I forgot to file this. I will file
> it.
> Hopefully that will prod someone to fix it.
>
> And to this from Christian.
>
> > I've seen this error on various toolchains. I believe it to be a gcc
> > bug; however, since it still seems to be an issue on some platforms,
> > maybe gdb should avoid using global (nonstatic) threadlocal
> > variables... (and instead abstract access to this variable through
> > getters/setters)
>
> I emailed Corrina from Cygwin and she thought it was a gdb issue
> and not a Cygwin issue. I didn't know which project was best to file
> this on.
>
> I'm not sure of the solution and based on the results from a Google
> search people just hack around it. It does need a proper solution.
>
> --joel
>
>>
>>
>> Hannes
>>
>
More information about the Gdb
mailing list