__xstat et al. as compat symbols
Adhemerval Zanella
adhemerval.zanella@linaro.org
Thu Oct 22 18:04:40 GMT 2020
On 22/10/2020 13:40, Adhemerval Zanella wrote:
>
>
> On 22/10/2020 12:37, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> Thanks for bring this up, and I agree with you that this breakage might
>>> incur in more headaches than solutions. I will send a fix to export
>>> the xstat symbols in static objects as well, while preserving the compat
>>> symbols on shared objects.
>>
>> Sorry, I do not see how the compat symbols work for the Ocaml use case?
>> The compat symbol is what creates the Ocaml link failure. It has to be
>> a non-compat symbol. We have to rely on lack of use in the installed
>> headers (which does not seem to be a real problem in this particular
>> case).
>
> So the issue is Ocaml is providing static libraries that are meant to
> generate dynamic linked binaries? Does it provide the same facility to
> build static binaries and if it were the case, how this is done?
>
> In the end, do still need to keep providing the xstat symbols in the
> static library as well or just remove the compat symbol directive would
> be suffice?
>
>>
>> By the way, I verified that glibc 2.0 binaries without symbol versioning
>> can bind to the __xstat compat symbol. Apparently binaries can do that
>> as long as they do not contain any version information at all:
>>
>> 165100: binding file /home/fweimer/src/my/glibc-test-binaries/gcc-2.7.2.3/i386/root/usr/bin/gcc [0] to ./libc.so.6 [0]: normal symbol `__xstat'
Ok, I understood better the scenario Ocaml might be doing and this is
another fallback of using the libc_noshared wrapper. I will send patch
to revert and fix the fix the build for newer ABIS.
More information about the Libc-alpha
mailing list