[PATCH 1/2] Revert "linux: Move {f}xstat{at} to compat symbols"

[Adhemerval Zanella]

On 24/12/2020 11:28, Florian Weimer wrote:
> * Andreas Schwab:
> 
>> On Dez 24 2020, Florian Weimer wrote:
>>
>>> * Andreas Schwab:
>>>
>>>> On Okt 22 2020, Adhemerval Zanella via Libc-alpha wrote:
>>>>
>>>>> This reverts commit 20b39d59467b0c1d858e89ded8b0cebe55e22f60 to
>>>>> moke {f}xstat{at} default symbols.
>>>
>>> How does this present itself as a problem?
>>
>> configure:3190: checking whether g++ can link programs
>> configure:3213: g++ -o conftest -g -O2   conftest.cpp  >&5
>> configure:3213: $? = 0
>> configure:3236: g++ -o conftest -g -O2   -static conftest.cpp  >&5
>> /usr/lib/gcc/i586-suse-linux/10/../../../../i586-suse-linux/bin/ld: /usr/lib/gc\
>> c/i586-suse-linux/10/libstdc++.a(basic_file.o): in function `std::__basic_file<\
>> char>::showmanyc()':
>> /usr/include/sys/stat.h:518: undefined reference to `__fxstat64'
>> collect2: error: ld returned 1 exit status
> 
> Is this our g++ linker test?
> 
> Testing static linking against libstdc++ is somewhat unusual.
> 
>>> Building against an older glibc for static linking against a future
>>> glibc seems a rather fringe use case to me.
>>
>> That basically means you have to rebuild the world, due to the ubiquity
>> of stat etc.
> 
> Is static linking really that prevalent?
> 
> But I had not considered the libstdc++ case.  So maybe we need to
> preserve these symbols for a while, even for static linking.
> 

I saw this issue when making the patch for riscv32, where the old toolchain
libstdc++ was configured to use the xstat symbols (I had to bootstrap the
toolchain).