This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
Hi, On 05/22/2013 11:59 AM, Jonathan Wakely wrote:
I don't think it could be available on older systems without something like --enable-libstdcxx-time=rt on the command line. That is, without a non-default configure switch. Anyway, indeed it could be available, depending on the configuration and we wanted it to be exported, in case. I think there isn't a risk of real, substantive abi-breakage here, the issue is largely about the way we are testing abi_check. I bet Jakub has ideas about the best way to approach this, like with the alias mechanism?!? Essentially we want to arrange things in such a way that this specific symbol is fine to be optionally exported at *any* version >= GLIBCXX_3.4.17 (thus, no abi_check error), depending on the configure switch.On 22 May 2013 10:47, Paolo Carlini wrote:Could you please double check abi_check? On this glibc 2.17 machine I'm seeing: 1 incompatible symbols 0 _ZNSt6chrono12steady_clock3nowEv std::chrono::steady_clock::now() version status: incompatible GLIBCXX_3.4.17 type: function status: added I'm going to try again, just in case I goofed something.No, I don't think you goofed, I see it too on glibc 2.17, sorry about that. How should we handle that export? It is available on older systems without glibc 2.17 and with older GCC versions if you configure with --enable-libstdcxx-time=rt,
Paolo.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |