This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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]

Re: libstdc++ wants clock_gettime without libpthread


> i don't think the additional bloat is large.  on x86_64:

Fair enough.  In non-Linux configurations, or configurations for older
Linux kernels we have only recently stopped supporting, the code could well
be a lot larger.  But given all the other issues, this does seem like the
right trade-off.

> librt.so is linked against libc.so, so anything that is linked against those 
> symbols should be able to find them automatically.  similarly, if someone were 
> to dlopen(librt.so), the dlsym() will search the library's dependency tree 
> (which libc.so is in), so it'd still be found.  what use case would 
> necessitate keeping forwarding symbols in librt.so ?

Symbol version binding is to SONAME as well as version set name.
Moving a symbol from one DSO to another is always an ABI change.

> worse comes to worse, we could leverage IFUNC when available and have
> fallback code to support targets that don't support IFUNC yet.

That's necessary if we make the change any time soon, since there are still
some machines without IFUNC support.  In principle I certainly don't mind
just implementing it with IFUNC now and leaving the non-IFUNC code to
people working on such machines.  But in fact, the support is trivial
enough (the obvious thing being just wrapper functions doing tail calls
to GLIBC_PRIVATE __clock_* functions exported by libc).


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]