[filesystem] gcc-3.4.3, fstream_test
For this sole failure on the tests that I run: http://tinyurl.com/92zns I did some investigation and narrowed the problem down to this: ===basic_iostream_char_test.cpp=== #include <fstream> struct my_fstream : public std::basic_fstream<char> { my_fstream() : std::basic_fstream<char>("basic_iostream_char_test.cpp") { } }; int main(int argc, char** argv) { my_fstream f; } ===basic_iostream_char_test.cpp=== Which gives a link error of: undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()' And AFAICT that particular dtor is not in libstdc++. And for that matter the entire std::basic_iostream<char,..> instance is missing. The strange aspect of this is that this exact test passes on Martin's tests. And of course it's only with this particular gcc. When I compile with 3.3.5, on the same machine, the symbols exist. Could others try compiling the above code? Just need to see if it's just my machine that has this problem before I file a GCC bug report. --grafik
"Rene Rivera" <grafik.list@redshift-software.com> wrote in message news:427E5062.6020705@redshift-software.com...
For this sole failure on the tests that I run:
I did some investigation and narrowed the problem down to this:
===basic_iostream_char_test.cpp=== #include <fstream>
struct my_fstream : public std::basic_fstream<char> { my_fstream() : std::basic_fstream<char>("basic_iostream_char_test.cpp") { } };
int main(int argc, char** argv) { my_fstream f; } ===basic_iostream_char_test.cpp===
Which gives a link error of:
undefined reference to `std::basic_iostream<char, std::char_traits<char>
::~basic_iostream()'
And AFAICT that particular dtor is not in libstdc++. And for that matter the entire std::basic_iostream<char,..> instance is missing.
The strange aspect of this is that this exact test passes on Martin's tests. And of course it's only with this particular gcc. When I compile with 3.3.5, on the same machine, the symbols exist.
Could others try compiling the above code? Just need to see if it's just my machine that has this problem before I file a GCC bug report.
Works fine on 3.3.3 (cygwin special). I don't appear to have 3.4.3 installed on any machine here. --Beman
On Sun, May 08, 2005 at 12:46:10PM -0500, Rene Rivera wrote:
For this sole failure on the tests that I run:
I did some investigation and narrowed the problem down to this:
===basic_iostream_char_test.cpp=== #include <fstream>
struct my_fstream : public std::basic_fstream<char> { my_fstream() : std::basic_fstream<char>("basic_iostream_char_test.cpp") { } };
int main(int argc, char** argv) { my_fstream f; } ===basic_iostream_char_test.cpp===
Which gives a link error of:
undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()' [...] Could others try compiling the above code? Just need to see if it's just my machine that has this problem before I file a GCC bug report.
I had no problem building basic_iostream_char_test with gcc 3.4.2, 3.4.3, and 4.0.0 on i686-pc-linux-gnu. (No specific command line options, all compilers configured with --enable-threads=posix --enable-version-specific-runtime-libs \ --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar \ --enable-libstdcxx-debug --enable-c99 --enable-libstdcxx-pch) Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
On Sun, May 08, 2005 at 12:46:10PM -0500, Rene Rivera wrote:
For this sole failure on the tests that I run:
I did some investigation and narrowed the problem down to this: [snip testcase] Which gives a link error of:
undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()'
And AFAICT that particular dtor is not in libstdc++. And for that matter the entire std::basic_iostream<char,..> instance is missing.
I've had very similar problems with that dtor missing from libstdc++, see http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html (despite the subject line, this was nothing to do with PR16715, that just made a latent problem apparent) Could you check whether the wchar_t specialisation is in the libstdc++.so library? nm --demangle libstdc++.so | grep 'basic_iostream<wchar_t' Both the char and wchar_t specialisations should be in the lib, thanks to explicit instantiation in istream.tcc This problem eventually went away IIRC, I was tracking the CVS version and stopped having the problem at some point. jon
Jonathan Wakely wrote:
On Sun, May 08, 2005 at 12:46:10PM -0500, Rene Rivera wrote:
For this sole failure on the tests that I run:
I did some investigation and narrowed the problem down to this:
[snip testcase]
Which gives a link error of:
undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()'
And AFAICT that particular dtor is not in libstdc++. And for that matter the entire std::basic_iostream<char,..> instance is missing.
I've had very similar problems with that dtor missing from libstdc++, see http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html (despite the subject line, this was nothing to do with PR16715, that just made a latent problem apparent)
That doesn't seem to have any resolutions to it. Did I miss something? What was the resolution?
Could you check whether the wchar_t specialisation is in the libstdc++.so library?
nm --demangle libstdc++.so | grep 'basic_iostream<wchar_t'
Had already done that.. which is why I said the char specializations where absent. The wchar_t ones are present.
Both the char and wchar_t specialisations should be in the lib, thanks to explicit instantiation in istream.tcc
Not in my case :-(
This problem eventually went away IIRC, I was tracking the CVS version and stopped having the problem at some point.
Well it doesn't help me :-( As this is the straight release tar archive. And as was pointed out on another post, it's only my problem. Others have those symbols with the 3.4.3 release. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Sun, May 08, 2005 at 10:49:32PM -0500, Rene Rivera wrote:
Jonathan Wakely wrote:
On Sun, May 08, 2005 at 12:46:10PM -0500, Rene Rivera wrote:
For this sole failure on the tests that I run:
I did some investigation and narrowed the problem down to this:
[snip testcase]
Which gives a link error of:
undefined reference to `std::basic_iostream<char, std::char_traits<char> >::~basic_iostream()'
And AFAICT that particular dtor is not in libstdc++. And for that matter the entire std::basic_iostream<char,..> instance is missing.
I've had very similar problems with that dtor missing from libstdc++, see http://gcc.gnu.org/ml/libstdc++/2004-09/msg00125.html (despite the subject line, this was nothing to do with PR16715, that just made a latent problem apparent)
That doesn't seem to have any resolutions to it. Did I miss something? What was the resolution?
No, I was never able to figure out what was going on and the problem went away eventually. I wasn't sure it wasn't something I'd done wrong on my system, it worked fine for everyone else, so didn't file a bug report. Now that I think about it, the problem *might* have disappeared when I upgraded from Fedora Core 1 to 2, so an upgraded binutils might have fixed it.
Could you check whether the wchar_t specialisation is in the libstdc++.so library?
nm --demangle libstdc++.so | grep 'basic_iostream<wchar_t'
Had already done that.. which is why I said the char specializations where absent. The wchar_t ones are present.
Both the char and wchar_t specialisations should be in the lib, thanks to explicit instantiation in istream.tcc
Not in my case :-(
That must be the exact same issue as I had.
This problem eventually went away IIRC, I was tracking the CVS version and stopped having the problem at some point.
Well it doesn't help me :-( As this is the straight release tar archive. And as was pointed out on another post, it's only my problem. Others have those symbols with the 3.4.3 release.
I suggest filing a PR in bugzilla, giving the full configure command used to build the compiler and giving the URL to the thread I started on the subject. I'll add what I can to it, including that upgrading binutils might have been what solved it. If you have a compiler exhibiting the problem at the moment you'll be able to give more details than me, as I no longer have the problem. jon -- Bullshit makes the flowers grow & that's beautiful
participants (4)
-
Beman Dawes -
Christoph Ludwig -
Jonathan Wakely -
Rene Rivera