This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH, v3] Potential solution to librt issue.
On Wed, Jul 23, 2008 at 11:54 PM, Chris Fairles <chris.fairles@gmail.com> wrote:
>
>
> Daniel Jacobowitz-2 wrote:
>>
>> On Wed, Jul 23, 2008 at 02:14:07PM +0200, Paolo Bonzini wrote:
>>>>>>> libstdc___la_DEPENDENCIES = ${version_dep} \
>>>>>>> $(top_builddir)/libmath/libmath.la \
>>>>>>> $(top_builddir)/libsupc++/libsupc++convenience.la
>>>>>> Updated patch w/ suggested changes. Changelog remains the same.
>>>>>
>>>>> You did not update libstdc___la_DEPENDENCIES, because GLIBCXX_LIBS does
>>>>> not
>>>>> belong there. :-)
>>>>
>>>> Oh yeah. It does tack libadd on the end doesn't it. Updated (its
>>>> early, eyes aren't working yet).
>>>
>>> Ok for trunk.
>>
>> If I'm reading this right, libstdc++ now requires librt to link. Is
>> that correct? If not, please ignore the rest of this message.
>>
>> First of all, I think this will g++ -static. The compiler knows about
>> the previous libm dependency, but not the new librt dependency.
>>
>> Second of all, linking in librt on Linux also requires libpthread;
>> this is going to make all C++ programs link in libpthread, which
>> activates locking in glibc (a major overhead for single-threaded
>> programs).
>>
>> --
>> Daniel Jacobowitz
>> CodeSourcery
>>
>>
>
> What about --disable-posix-timers == #undef _POSIX_TIMERS or effect thereof?
> default 'on' in favor of mt apps? single-threaded apps would just fall back
> to gettimeofday (micosec res on posix), or std::time() if even gtod is not
> avail.
>
> Chris
>
> PS.
>
> FYI, x86_64 (centos 4.4), a short snip:
> #include <chrono>
> int main() {
> cout << chrono::system_clock::now().time_since_epoch() << endl;
> }
>
> pruduces the following deps (from ldd)
>
> librt.so.1 => /lib64/tls/librt.so.1
> libstdc++.so.6 => /home/cfairles/lib64/libstdc++.so.6
> libm.so.6 => /lib64/tls/libm.so.6
> libgcc_s.so.1 => /home/cfairles/lib64/libgcc_s.so.1
> libc.so.6 => /lib64/tls/libc.so.6
> libpthread.so.0 => /lib64/tls/libpthread.so.0
> /lib64/ld-linux-x86-64.so.2
>
> Unfortunately their inclusion is unconditional at the moment so even a
> trivial app requires the same deps.
> --
> View this message in context: http://www.nabble.com/-PATCH%2C-v3--Potential-solution-to-librt-issue.-tp18603751p18625031.html
> Sent from the gcc - libstdc++ mailing list archive at Nabble.com.
>
>
Bah. What am I talking about, that will never work. How can you know
during link time that the code actually requires the symbols and have
it conditionally add -lrt? Seems rather involved.
Chris