This is the mail archive of the
mailing list for the libstdc++ project.
Re: --enable-libstdcxx-time changes ABI?
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Kenny Simpson <theonetruekenny at yahoo dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Mon, 3 Dec 2012 09:43:18 +0000
- Subject: Re: --enable-libstdcxx-time changes ABI?
- References: <1354422995.50985.YahooMailClassic@web39404.mail.mud.yahoo.com>
On 2 December 2012 04:36, Kenny Simpson wrote:
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html documents the --enable-libstdcxx-time options, but, unlike some of the other options, does not mention that it affects ABI.
> or maybe I'm not understanding ABI-breakage.
> My understanding of the affect of this is that std::chrono::system_clock::time_point would become a different type.
> std::chrono::system_clock::time_point is defined as:
> typedef chrono::time_point<system_clock, duration> time_point;
> and 'duration' depends on a configuration-time setting based the enable-libstdcxx-time:
> struct system_clock
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
> typedef chrono::nanoseconds duration;
> #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
> typedef chrono::microseconds duration;
> typedef chrono::seconds duration;
> What makes this affect the ABI is system_clock::now:
> static time_point
> now() noexcept;
> Since only the return type is affected, and since the return type is not part of the mangled name, the exported symbol is not affected.
> However, if a program at runtime were to run against a libstdc++.so built with a differing option, the results would be times/durations that are off by large factors - silently. The program could have compiled assuming nanoseconds, only to run against a libstdc++ that returns microseconds.
> As such, it seems it would never be safe to mix code that was built with differing flavors of libstdcxx-time. If this is true, a note in the documentation would be nice - even if this isn't considered ABI-breakage since the exported symbols aren't affected.
I agree this should be documented, I'll update the docs for
N.B. currently the higher resolution system_clock is only available
with --enable-libstdcxx-time=rt which causes libstdc++.so to link to
librt.so, which is a very user-visible change (although maybe not an
obvious one unless you look for it.) At some point a future version
of GCC when used with glibc 2.17 or later will be able to use
clock_gettime and CLOCK_REALTIME without librt.so, which would
effectively make --enable-libstdcxx-time=rt equivalent to
--enable-libstdcxx-time=yes and we will need to keep in mind that it
can affect the ABI.
I wonder if we want to use the abi tag attribute to make system_clock
mangle differently depending whether it uses nanosecond, microsecond
or second resolution.