Bug#932546: g++-8 fails to build C++17 programs that use std::filesystem
Package: g++-8
Version: 8.3.0-6
Severity: important
Dear Maintainer,
* What led up to the situation?
Using std::filesystem::directory_iterator in a C++17 program.
* What exactly did you do (or not do) that was effective (or ineffective)?
Compile and link the program.
Originally I was trying to build third-party free software, but I wrote
a trivial test case that demonstrates the same behaviour to eliminate
potential CMake configuration issues in the third-party software from
consideration. Here follows the test case source code, called "foo.cc":
#include
#include
int main()
{
std::filesystem::directory_iterator bob(".");
for (auto p = begin(bob); p != end(bob); ++p)
{
printf("%s\n", p->path().c_str());
}
return 0;
}
* What was the outcome of this action?
"g++ -std=c++17 foo.cc" failed at the linking step; shell transcript
follows:
mormegil@phlegethon:~/src/native/foo$ g++ -std=c++17 foo.cc
/usr/bin/ld: /tmp/ccjRDL0f.o: in function `main':
foo.cc:(.text+0x123): undefined reference to
`std::filesystem::__cxx11::directory_iterator::operator++()'
/usr/bin/ld: /tmp/ccjRDL0f.o: in function
`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&)':
foo.cc:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC5ERKNS0_4pathE]+0x26):
undefined reference to
`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&, std::filesystem::directory_options, std::error_code*)'
/usr/bin/ld: /tmp/ccjRDL0f.o: in function
`std::filesystem::__cxx11::directory_iterator::operator->() const':
foo.cc:(.text._ZNKSt10filesystem7__cxx1118directory_iteratorptEv[_ZNKSt10filesystem7__cxx1118directory_iteratorptEv]+0x14):
undefined reference to
`std::filesystem::__cxx11::directory_iterator::operator*() const'
/usr/bin/ld: /tmp/ccjRDL0f.o: in function
`std::filesystem::__cxx11::path::path(char const (&) [2],
std::filesystem::__cxx11::path::format)':
foo.cc:(.text._ZNSt10filesystem7__cxx114pathC2IA2_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5IA2_cS1_EERKT_NS1_6formatE]+0x5e):
undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
collect2: error: ld returned 1 exit status
mormegil@phlegethon:~/src/native/foo$
* What outcome did you expect instead?
I expected g++ to compile and link my test case included in this email
and also to compile and link the large third-party free software package
(the Eternity Engine, a fork of the libre source code for Doom).
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages g++-8 depends on:
ii gcc-88.3.0-6
ii gcc-8-base 8.3.0-6
ii libc62.28-10
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++-8-dev 8.3.0-6
ii zlib1g 1:1.2.11.dfsg-1
g++-8 recommends no packages.
Versions of packages g++-8 suggests:
pn g++-8-multilib
pn gcc-8-doc
pn libstdc++6-8-dbg
-- no debconf information
Bug#932548: g++-8: g++ fails to compile C++17 programs that use std::filesystem::directory_iterator
Package: g++-8
Version: 8.3.0-6
Severity: important
Dear Maintainer,
* What led up to the situation?
Using std::filesystem::directory_iterator in a C++17 program.
* What exactly did you do (or not do) that was effective (or ineffective)?
Attempt to compile and link the program.
Originally I was trying to build third-party free software, but I wrote
a trivial test case that demonstrates the same behaviour to eliminate
potential CMake configuration issues in the third-party software from
consideration. Here follows the test case source code, called "foo.cc":
#include
#include
int main()
{
std::filesystem::directory_iterator bob(".");
for (auto p = begin(bob); p != end(bob); ++p)
{
printf("%s\n", p->path().c_str());
}
return 0;
}
* What was the outcome of this action?
"g++ -std=c++17 foo.cc" failed at the linking step; shell transcript
follows:
mormegil@phlegethon:~/src/native/foo$ g++ -std=c++17 foo.cc
/usr/bin/ld: /tmp/ccjRDL0f.o: in function `main':
foo.cc:(.text+0x123): undefined reference to
`std::filesystem::__cxx11::directory_iterator::operator++()'
/usr/bin/ld: /tmp/ccjRDL0f.o: in function
`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&)':
foo.cc:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC5ERKNS0_4pathE]+0x26):
undefined reference to
`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&, std::filesystem::directory_options, std::error_code*)'
/usr/bin/ld: /tmp/ccjRDL0f.o: in function
`std::filesystem::__cxx11::directory_iterator::operator->() const':
foo.cc:(.text._ZNKSt10filesystem7__cxx1118directory_iteratorptEv[_ZNKSt10filesystem7__cxx1118directory_iteratorptEv]+0x14):
undefined reference to
`std::filesystem::__cxx11::directory_iterator::operator*() const'
/usr/bin/ld: /tmp/ccjRDL0f.o: in function
`std::filesystem::__cxx11::path::path(char const (&) [2],
std::filesystem::__cxx11::path::format)':
foo.cc:(.text._ZNSt10filesystem7__cxx114pathC2IA2_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5IA2_cS1_EERKT_NS1_6formatE]+0x5e):
undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
collect2: error: ld returned 1 exit status
mormegil@phlegethon:~/src/native/foo$
* What outcome did you expect instead?
I expected g++ to compile and link my test case included in this email
and also to compile and link the large third-party free software package
(the Eternity Engine, a fork of the libre source code for Doom).
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages g++-8 depends on:
ii gcc-88.3.0-6
ii gcc-8-base 8.3.0-6
ii libc62.28-10
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++-8-dev 8.3.0-6
ii zlib1g 1:1.2.11.dfsg-1
g++-8 recommends no packages.
Versions of packages g++-8 suggests:
pn g++-8-multilib
pn gcc-8-doc
pn libstdc++6-8-dbg
-- no debconf information
Bug#512129: (no subject)
Package: g++-4.3
Version: 4.3.2-1.1
When compiling a program which used the C++ STL to contain instances of a class
of my own devising, I encountered spurious warnings. I have been able to reduce
the necessary code to a simple test case, which is included in this bug report
along with a transcript of the spurious warninngs seen when compiling it.
morme...@fangasm:~/src/dungeonbash-2.0.0$ uname -a
Linux fangasm 2.6.26-1-686 #1 SMP Wed Nov 26 19:14:11 UTC 2008 i686 GNU/Linux
morme...@fangasm:~/src/dungeonbash-2.0.0$ g++ --version
g++ (Debian 4.3.2-1.1) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
morme...@fangasm:~/src/dungeonbash-2.0.0$ make coordtest
g++ -c -g -Wall -Wwrite-strings -Wredundant-decls -Wunreachable-code
-DMAJVERS=2 -DMINVERS=0 -DPATCHVERS=0 -c -o coordtest.o coordtest.cc
coordtest.cc: In member function âT libmrl::basic_coord::distance(const
libmrl::basic_coord&) const [with T = int]â:
coordtest.cc:28: warning: will never be executed
coordtest.cc: In member function âbool
libmrl::basic_coord::operator<(const libmrl::basic_coord&) const [with T
= int]â:
coordtest.cc:20: warning: will never be executed
/usr/include/c++/4.3/bits/stl_tree.h: In member function
âstd::_Rb_tree_node<_Val>* std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_create_node(const _Val&) [with _Key = libmrl::basic_coord,
_Val = libmrl::basic_coord, _KeyOfValue =
std::_Identity >, _Compare =
std::less >, _Alloc =
std::allocator >]â:
/usr/include/c++/4.3/bits/stl_tree.h:369: warning: will never be executed
/usr/include/c++/4.3/bits/stl_tree.h:372: warning: will never be executed
/usr/include/c++/4.3/bits/stl_tree.h:369: warning: will never be executed
g++ coordtest.o -o coordtest
morme...@fangasm:~/src/dungeonbash-2.0.0$
morme...@fangasm:~$ ls -l /lib/libc.so.6
lrwxrwxrwx 1 root root 11 2008-12-17 22:00 /lib/libc.so.6 -> libc-2.7.so
morme...@fangasm:~$
The test case follows:
#include
#include
#include
namespace libmrl
{
template class basic_coord
{
public:
T y;
T x;
basic_coord& operator -=(basic_coord const& right) throw()
{
y -= right.y; x -= right.x; return *this;
}
basic_coord& operator +=(basic_coord const& right) throw()
{
y += right.y; x += right.x; return *this;
}
bool operator < (basic_coord const& right) const throw()
{
return (y < right.y) || ((y == right.y) && (x < right.x));
}
bool operator == (basic_coord const& right) const throw()
{
return (y == right.y) && (x == right.x);
}
T distance(basic_coord const& right) const throw()
{
T dy, dx;
dy = right.y - y;
dx = right.x - x;
if (dy < 0) dy = -dy;
if (dx < 0) dx = -dx;
return (dy > dx) ? dy : dx;
}
};
typedef basic_coord Coord;
}
int main()
{
libmrl::Coord c = { 1, 2 };
libmrl::Coord d = { 3, 4 };
std::printf("%d %d to %d %d: distance %d or %d\n", c.y, c.x, d.y, d.x,
c.distance(d), d.distance(c));
std::list oink;
oink.push_front(c);
oink.push_front(d);
std::printf("%d\n", oink.size());
std::set spang;
spang.insert(c);
spang.insert(d);
std::printf("%d\n", spang.size());
}
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
