Re: [PATCH] Implement LWG 2686, hash<error_condition>

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 09/05/2019 16:16, Jonathan Wakely wrote:
> On Thu, 9 May 2019 at 15:43, Szabolcs Nagy <Szabolcs.Nagy@arm.com> wrote:
>> On 07/05/2019 13:21, Christophe Lyon wrote:
>>> On Tue, 7 May 2019 at 12:07, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>> On 07/05/19 10:37 +0100, Jonathan Wakely wrote:
>>>>> On 07/05/19 11:05 +0200, Christophe Lyon wrote:
>>>>>> I'm seeing link failures on arm-eabi (using newlib):
>>>>>> Excess errors:
>>>>>> /libstdc++-v3/src/c++17/fs_ops.cc:806: undefined reference to `chdir'
>>>>>> /libstdc++-v3/src/c++17/fs_ops.cc:583: undefined reference to `mkdir'
>>>>>> /libstdc++-v3/src/c++17/fs_ops.cc:1134: undefined reference to `chmod'
>>>>>> /libstdc++-v3/src/c++17/../filesystem/ops-common.h:439: undefined
>>>>>> reference to `chmod'
>>>>>> /libstdc++-v3/src/c++17/fs_ops.cc:750: undefined reference to `pathconf'
>>>>>> /libstdc++-v3/src/c++17/fs_ops.cc:769: undefined reference to `getcwd'
>>>>>>
>>>>>> Christophe
>>>>
>>>> Is it definitely the new 19_diagnostics/error_condition/hash.cc test
>>>> that's giving this error?
>>
>> i looked at this and ld -M reports
>>
>> /B/aarch64-none-elf/libstdc++-v3/src/.libs/libstdc++.a(system_error.o)
>>         hash.o (std::_V2::error_category::default_error_condition(int) const)
>> /B/aarch64-none-elf/libstdc++-v3/src/.libs/libstdc++.a(fs_ops.o)
>>         /B/aarch64-none-elf/libstdc++-v3/src/.libs/libstdc++.a(system_error.o) (void std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >::_M_construct<char const*>(char const*, char const*, std::forward_iterator_tag))
>> ...
>>
>> i.e. hash.o pulls system_error.o in because of
>>
>>   std::_V2::error_category::default_error_condition(int) const
>>
>> and system_error.o pulls fs_ops.o in because of
>>
>>   std::__cxx11::basic_string...
>>
>> symbol reference.
>>
>> it seems fs_ops.o is the first object in libstdc++.a
>> that provides a (weak) definition for
>>
>> _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag
> 
> Ah, so maybe we need an explicit instantiation elsewhere.
> Or completely disable all the stuff using chdir, mkdir etc for these
> newlib targets, which is probably a good idea anyway.

disabling fs things for baremetal makes sense.

but i would not expect system_error.o to depend
on fs_ops.o even on non-baremetal targets.

so whatever causes the dependency should be fixed
as well i think.

in this case the base_string_whatever should have
a definition either in system_error.o or in a .o
with minimal deps that is guaranteed to come before
fs_ops.o in libstdc++.a