[PATCH, v3] Potential solution to librt issue.

[Chris Fairles]

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.