Your message dated Sun, 18 Dec 2022 15:07:53 +0100
with message-id <[email protected]>
and subject line Re: Bug#946876: mingw32: Linking failure when using
std::experimental::filesystem
has caused the Debian Bug report #946876,
regarding mingw32: Linking failure when using std::experimental::filesystem
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
946876: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946876
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: g++-mingw-w64-x86-64
Version: 8.3.0-6+21.3~deb10u1
Severity: normal
Tags: patch
Dear Maintainer,
I had some issues linking an application being built as C++14 and using the
std::experimental::filesystem -
it mentioned unresolved "fs_err_concat" symbols. When researching it, I
discovered this page,
which explained the exact message and contained a patch.
https://patches-gcc.linaro.org/patch/12753/#22525
Apparently a change elsewhere removed a symbol that the experimental filesystem
support was still using,
and my testing suggests that the Debian package lacks this patch.
I've added the patch to the Buster package here:
https://salsa.debian.org/mingw-w64-team/gcc-mingw-w64/merge_requests/1
and I've confirmed that it applies and starts building - I didn't have the
storage space to run the build
to completion locally.
The minimized test file is attached: the comment explains how to build and link
as either C++17
(using std::filesystem - this works) or C++14 (using
std::experimental::filesystem, produces the error)
I suspect newer upstream (e.g. not Buster) already contains the patch, but this
test file should make it easy to check.
The error message is:
/usr/bin/x86_64-w64-mingw32-ld:
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libstdc++fs.a(path.o):(.text$_ZNSt12experimental10filesystem2v17__cxx1116filesystem_error11_M_gen_whatEv+0x639):
undefined reference to
`std::filesystem::fs_err_concat(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
Thank you!
Ryan
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages g++-mingw-w64-x86-64 depends on:
ii gcc-mingw-w64-base 8.3.0-6+21.3~deb10u1
ii gcc-mingw-w64-x86-64 8.3.0-6+21.3~deb10u1
ii libc6 2.28-10
ii libgcc1 1:8.3.0-6
ii libgmp10 2:6.1.2+dfsg-4
ii libisl19 0.20-2
ii libmpc3 1.1.0-1
ii libmpfr6 4.0.2-1
ii libstdc++6 8.3.0-6
ii zlib1g 1:1.2.11.dfsg-1
g++-mingw-w64-x86-64 recommends no packages.
Versions of packages g++-mingw-w64-x86-64 suggests:
pn gcc-8-locales <none>
-- no debconf information
/*
This builds and links:
$ x86_64-w64-mingw32-g++ -std=c++17 demo.cpp -o demo17.o -Wl,--no-undefined
-lstdc++fs
This fails to link:
$ x86_64-w64-mingw32-g++ -std=c++14 demo.cpp -o demo14.o -Wl,--no-undefined
-lstdc++fs
/usr/bin/x86_64-w64-mingw32-ld:
/usr/lib/gcc/x86_64-w64-mingw32/8.3-win32/libstdc++fs.a(path.o):(.text$_ZNSt12experimental10filesystem2v17__cxx1116filesystem_error11_M_gen_whatEv+0x639):
undefined reference to
`std::filesystem::fs_err_concat(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
*/
// If the C++ macro is set to the version containing C++17, it must support
// the final C++17 package
#if __cplusplus >= 201703L
#include <filesystem>
namespace fs = std::filesystem;
#else
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
#endif
bool is_reg_file(const std::string &path) { return fs::is_regular_file(path); }
int main() {
(void)is_reg_file("/etc/os-release");
return 0;
}
--- End Message ---
--- Begin Message ---
Version: 24.2
On Mon, Dec 16, 2019 at 05:43:28PM -0600, Ryan Pavlik wrote:
> The minimized test file is attached: the comment explains how to build and
> link as either C++17
> (using std::filesystem - this works) or C++14 (using
> std::experimental::filesystem, produces the error)
> I suspect newer upstream (e.g. not Buster) already contains the patch, but
> this test file should make it easy to check.
That is correct, this is fixed since Bullseye. Given that there is a
workaround for Buster (build with C++17) I’m not sure this warrants a
fix there.
Regards,
Stephen
signature.asc
Description: PGP signature
--- End Message ---
