On 09/05/2019 16:16, Jonathan Wakely wrote: > On Thu, 9 May 2019 at 15:43, Szabolcs Nagy <szabolcs.n...@arm.com> wrote: >> On 07/05/2019 13:21, Christophe Lyon wrote: >>> On Tue, 7 May 2019 at 12:07, Jonathan Wakely <jwak...@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