On Thu, 31 Aug 2023, 18:43 Jonathan Wakely via Libstdc++, < libstdc++@gcc.gnu.org> wrote: > On Thu, 31 Aug 2023 at 16:26, Christophe Lyon > wrote: > > > > As discussed in PR104167 (comments #8 and below), and PR111238, using > > -Wl,-gc-sections in the libstdc++ testsuite for arm-eabi > > (cross-toolchain) avoids link failures for a few tests: > > > > 27_io/filesystem/path/108636.cc > > I think this one probably just needs { dg-require-filesystem-ts "" } > because there's no point testing that we can link to the > std::filesystem definitions if some of those definitions are unusable > on the target. > > // { dg-additional-options "-Wl,--gc-sections" { target gc_sections } } > Oops, ignore this line! I was going to suggest that we could work try adding this line, but I think it's better to use dg-require for the 108636.cc test, and make the ones below just work. > For the rest of them, does the attached patch help? If arm-eabi > doesn't define _GLIBCXX_HAVE_READLINK then there's no point even > trying to call filesystem::read_symlink. We can avoid a useless > dependency on it by reusing the same preprocessor condition that > filesystem::read_symlink uses. > > > std/time/clock/gps/1.cc > > std/time/clock/gps/io.cc > > std/time/clock/tai/1.cc > > std/time/clock/tai/io.cc > > std/time/clock/utc/1.cc > > std/time/clock/utc/io.cc > > std/time/clock/utc/leap_second_info.cc > > std/time/exceptions.cc > > std/time/format.cc > > std/time/time_zone/get_info_local.cc > > std/time/time_zone/get_info_sys.cc > > std/time/tzdb/1.cc > > std/time/tzdb/leap_seconds.cc > > std/time/tzdb_list/1.cc > > std/time/zoned_time/1.cc > > std/time/zoned_time/custom.cc > > std/time/zoned_time/io.cc > > std/time/zoned_traits.cc > > > > This patch achieves this by calling GLIBCXX_CHECK_LINKER_FEATURES in > > cross-build cases, like we already do for native builds. We keep not > > doing so in Canadian-cross builds. > > > > However, this would hide the fact that libstdc++ somehow forces the > > user to use -Wl,-gc-sections to avoid undefined references to chdir, > > mkdir, chmod, pathconf, ... so maybe it's better to keep the status > > quo and not apply this patch? > > I'm undecided about this for now, but let's wait for HP's cris-elf > testing anyway. >