__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