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 >