* Building on Mac with --enable-tls
@ 2020-03-18 19:14 Tom N
2020-03-18 23:05 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Tom N @ 2020-03-18 19:14 UTC (permalink / raw)
To: gcc-help
I'm trying to build GCC from source on Mac (darwin) and keep getting this error when --enable-tls is specified:
/var/folders/cq/wx4ff_gd0xncqh9qnbzmt2w40000gp/T//ccS0vBm1.s:9:2: error: unsupported symbol modifier
in relocation
leaq __ZN3GTM12_gtm_thr_tlsE@tlsgd(%rip), %rdi
^
make[5]: *** [alloc_cpp.lo] Error 1
If I either omit --enable-tls or specify --disable-tls the build succeeds, but then I get synchronization problems in my code which uses std::unique_lock<std::mutex> (namely it seems the synchronization isn't performed).
(Incidentally I've been building GCC for many years on Linux without issue so I'm not new to building GCC.)
I've tried on "fresh" (new system) Mac Yosemite (10.10), Sierra (10.12), and Catalina (10.15) (all having only XCode CLT, none have XCode itself), and GCC 4.9, 8.3, and 8.4. All fail the same. I've gleaned as much as I can from reading the Homebrew script that builds the same but still no luck.
I was hoping to find a build log from either GCC's own verification builds or Homebrew in order to compare against my own to find the problem but can't find it.
Here's the configure line from GCC 8.4 on Catalina (some of it may be unnecessary/redundant, it comes from my build toolchain):
cd ./build && CC=gcc CXX=g++ CFLAGS="" CXXFLAGS="" CPPFLAGS="" LDFLAGS="" BOOT_CFLAGS="-iframework /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks -mmacosx-version-min=10.15" CFLAGS_FOR_TARGET="-iframework /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Lib
rary/Frameworks -mmacosx-version-min=10.15" CXXFLAGS_FOR_TARGET="-iframework /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks -mmacosx-version-min=10.15" BOOT_LDFLAGS="-Wl,-headerpad_max_install_names" PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin /Users/me/gcc/gcc-8.4.0/configure --prefix=/Users/me/gcc_build --enable-languages=c,c++ --enable-threads=posix --enable-tls --disable-nls --enable-checking=release --disable-multilib --with-native-system-header-dir="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"
Happy to provide anything else that will help.
This has been beating me for a long time, appreciate anything.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building on Mac with --enable-tls
2020-03-18 19:14 Building on Mac with --enable-tls Tom N
@ 2020-03-18 23:05 ` Jonathan Wakely
2020-03-18 23:53 ` Iain Sandoe
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2020-03-18 23:05 UTC (permalink / raw)
To: Tom N; +Cc: gcc-help, Iain Sandoe
On Wed, 18 Mar 2020 at 19:15, Tom N <nospam@codesniffer.com> wrote:
>
> I'm trying to build GCC from source on Mac (darwin) and keep getting this error when --enable-tls is specified:
>
>
> /var/folders/cq/wx4ff_gd0xncqh9qnbzmt2w40000gp/T//ccS0vBm1.s:9:2: error: unsupported symbol modifier
> in relocation
> leaq __ZN3GTM12_gtm_thr_tlsE@tlsgd(%rip), %rdi
> ^
> make[5]: *** [alloc_cpp.lo] Error 1
>
>
> If I either omit --enable-tls or specify --disable-tls the build succeeds,
I would expect the default to be correct for the target i.e.
--disable-tls. If enabling it worked correctly, it would be the
default.
> but then I get synchronization problems in my code which uses std::unique_lock<std::mutex> (namely it seems the synchronization isn't performed).
That makes no sense, neither std::mutex nor std::unique_lock uses TLS.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building on Mac with --enable-tls
2020-03-18 23:05 ` Jonathan Wakely
@ 2020-03-18 23:53 ` Iain Sandoe
2020-03-19 13:54 ` Tom N
0 siblings, 1 reply; 6+ messages in thread
From: Iain Sandoe @ 2020-03-18 23:53 UTC (permalink / raw)
To: Tom N; +Cc: gcc-help, Jonathan Wakely
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On Wed, 18 Mar 2020 at 19:15, Tom N <nospam@codesniffer.com> wrote:
>> I'm trying to build GCC from source on Mac (darwin) and keep getting
>> this error when --enable-tls is specified:
>>
>>
>> /var/folders/cq/wx4ff_gd0xncqh9qnbzmt2w40000gp/T//ccS0vBm1.s:9:2: error:
>> unsupported symbol modifier
>> in relocation
>> leaq __ZN3GTM12_gtm_thr_tlsE@tlsgd(%rip), %rdi
>> ^
>> make[5]: *** [alloc_cpp.lo] Error 1
>>
>>
>> If I either omit --enable-tls or specify --disable-tls the build succeeds,
>
> I would expect the default to be correct for the target i.e.
> --disable-tls. If enabling it worked correctly, it would be the
> default.
>
>> but then I get synchronization problems in my code which uses
>> std::unique_lock<std::mutex> (namely it seems the synchronization isn't
>> performed).
>
> That makes no sense, neither std::mutex nor std::unique_lock uses TLS.
Darwin uses emulatedTLS on all versions (powerpc, i686, x86_64) the correct
default (to use emulatedTLS) is selected without requiring any additional
configure options. Selecting --enable-tls will undoubtedly produce an
invalid configuration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 is an enhancement PR to
add native TLS for 10.7+ (but that would still not work on earlier
versions, of course).
thanks
Iain
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building on Mac with --enable-tls
2020-03-18 23:53 ` Iain Sandoe
@ 2020-03-19 13:54 ` Tom N
2020-03-19 14:07 ` Jonathan Wakely
0 siblings, 1 reply; 6+ messages in thread
From: Tom N @ 2020-03-19 13:54 UTC (permalink / raw)
To: Iain Sandoe; +Cc: gcc-help, Jonathan Wakely
> On March 18, 2020 at 7:53 PM Iain Sandoe <idsandoe@googlemail.com> wrote:
>
> Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > I would expect the default to be correct for the target i.e.--disable-tls. If enabling it worked correctly, it would be the default.
> > That makes no sense, neither std::mutex nor std::unique_lock uses TLS.
>
> Darwin uses emulated TLS on all versions (powerpc, i686, x86_64) the correct default (to use emulatedTLS) is selected without requiring any additional configure options. Selecting --enable-tls will undoubtedly produce an invalid configuration.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 is an enhancement PR to add native TLS for 10.7+ (but that would still not work on earlier versions, of course).
Thank you both for the quick responses! Knowing that lack of --enable-tls is normal on Mac set me in the right direction. The synchronization problem was due to an equally bad assumption. All working as expected now.
Thanks again!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building on Mac with --enable-tls
2020-03-19 13:54 ` Tom N
@ 2020-03-19 14:07 ` Jonathan Wakely
2020-03-21 17:26 ` Tom N
0 siblings, 1 reply; 6+ messages in thread
From: Jonathan Wakely @ 2020-03-19 14:07 UTC (permalink / raw)
To: Tom N; +Cc: Iain Sandoe, gcc-help
On Thu, 19 Mar 2020 at 13:54, Tom N <nospam@codesniffer.com> wrote:
>
> > On March 18, 2020 at 7:53 PM Iain Sandoe <idsandoe@googlemail.com> wrote:
> >
> > Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > >
> > > I would expect the default to be correct for the target i.e.--disable-tls. If enabling it worked correctly, it would be the default.
> > > That makes no sense, neither std::mutex nor std::unique_lock uses TLS.
> >
> > Darwin uses emulated TLS on all versions (powerpc, i686, x86_64) the correct default (to use emulatedTLS) is selected without requiring any additional configure options. Selecting --enable-tls will undoubtedly produce an invalid configuration.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 is an enhancement PR to add native TLS for 10.7+ (but that would still not work on earlier versions, of course).
>
> Thank you both for the quick responses! Knowing that lack of --enable-tls is normal on Mac set me in the right direction. The synchronization problem was due to an equally bad assumption. All working as expected now.
Accidentally creating a temporary unique_lock that immediately goes
out of scope? :-)
http://kayari.org/cxx/antipatterns.html#locking-mutex
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building on Mac with --enable-tls
2020-03-19 14:07 ` Jonathan Wakely
@ 2020-03-21 17:26 ` Tom N
0 siblings, 0 replies; 6+ messages in thread
From: Tom N @ 2020-03-21 17:26 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: Iain Sandoe, gcc-help
> On March 19, 2020 at 10:07 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> Accidentally creating a temporary unique_lock that immediately goes out of scope? :-)
> http://kayari.org/cxx/antipatterns.html#locking-mutex
Not that bad I think. :) (The code has been in production on Linux & Windows for years so something like that should've popped up already.)
Actually the bad assumption was that my unit tests were doing sufficient testing of my GetThreadId wrapper. That wasn't working properly on Mac but not triggering an error either. The synchronization was not the problem--only the Thread IDs being used as keys into a std::map.
Thanks again!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-21 17:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-18 19:14 Building on Mac with --enable-tls Tom N
2020-03-18 23:05 ` Jonathan Wakely
2020-03-18 23:53 ` Iain Sandoe
2020-03-19 13:54 ` Tom N
2020-03-19 14:07 ` Jonathan Wakely
2020-03-21 17:26 ` Tom N
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).