开发者

How can I avoid dependency on GLIBC_X.Y when using weak symbols

开发者 https://www.devze.com 2023-03-08 17:28 出处:网络
While working on the signal implementation in Hurd, I have run into the following problem. Basically, I add a new function to glibc, which is used by libpthread (those are from separate sources on Hu

While working on the signal implementation in Hurd, I have run into the following problem.

Basically, I add a new function to glibc, which is used by libpthread (those are from separate sources on Hurd). In order for the new libpthread to still work with older glibc's, I declare the new function as a weak symbol in the libpthread code. (See the patch here.)

When libpthread is built with an older glibc, everything works as indended. However, when the symbol is actually found in glibc at build time, the linker emits a "VERNEED" corresponding to the new symbol's version and running with an older glibc results in:

foo: ./libc.so.0.3: version `GLIBC_X.Y' not found
(required by /lib/libpthread.so.0.3)

where GLIBC_X.Y is the version for the newly introduced symbol.

The result I'm looking for is for the new symbol to be N开发者_JAVA技巧ULL when glibc doesn't have it, which is what happens when I build libpthread with an older glibc.

Any idea how to fix this? Can I inhibit versionning for my symbol when linking libpthread?


So I used a weak alias to a default implementation instead of just a weak symbol compared to NULL, and for some reason it turns out the symbol version is not pulled in from glibc at link time.

0

精彩评论

暂无评论...
验证码 换一张
取 消