Re: Build Failure on Cygwin

Joel Sherrill <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CAF9ehCU2_r16tdLgRzWaqFM_3HqD33+sowQBb1Xa1aO-pOgu1g@mail.gmail.com>
On Mon, Oct 19, 2020 at 12:46 PM Hannes Domani <[email protected]> wrote:

>  Am Montag, 19. Oktober 2020, 19:26:28 MESZ hat Joel Sherrill <
> [email protected]> 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 <[email protected]>
> > 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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.