[Bug libstdc++/41005] New: Unable to link fstream open and ctor with std::string argument.

[Bug libstdc++/41005] New: Unable to link fstream open and ctor with std::string argument.

[3dw4rd at verizon dot net]

I was trying to build a simple app and use the std::string to build an ofstream
as allowed by C++-0X.

The source and header allows this.  You can compile but not link.

I've verified this on powerpc-apple-darwin7.9.0 and on x86_64-linux-unknown.

I think symbols are getting stripped out of the final library.

Here's a test case test_string_fstream.cpp
--------------------------------------------------------------

// ./bin/bin/g++ -std=c++0x -o test_string_fstream test_string_fstream.cpp

#include <string>
#include <fstream>

int
main()
{
  std::string name = "test.dat";
  std::ofstream stream( name );
}

--------------------------------------------------------------

MacOSX:~ ed$ ./bin/bin/g++ -std=c++0x -o test_string_fstream
test_string_fstream.cpp
/usr/bin/ld: Undefined symbols:
std::basic_ofstream<char, std::char_traits<char>
>::basic_ofstream(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&, std::_Ios_Openmode)

Here is the compiler specifics:

MacOSX:~ ed$ ./bin/bin/g++ -v                                                   
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc/configure --prefix=/Users/ed/bin --with-gmp=/usr/local
--with-mpfr=/usr/local --enable-languages=c,c++,fortran,objc,obj-c++ :
(reconfigured) ../gcc/configure --prefix=/Users/ed/bin --with-gmp=/usr/local
--with-mpfr=/usr/local --enable-languages=c,c++,fortran,objc,obj-c++
--no-create --no-recursion
Thread model: posix
gcc version 4.5.0 20090501 (experimental) (GCC) 

Thanks,

Ed


-- 
           Summary: Unable to link fstream open and ctor with std::string
                    argument.
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: 3dw4rd at verizon dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

------- Comment #1 from jwakely dot gcc at gmail dot com  2009-08-10 12:26 -------
Does libstdc++-v3/src/fstream-inst.cc get compiled in C++0x mode?  If not, then
the C++0x-only symbols would not be instantiated in the library


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

------- Comment #2 from jwakely dot gcc at gmail dot com  2009-08-10 13:17 -------
Since the C++0x changes to fstream are only additions, the simplest solution is
probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
new targets to src/Makefile.am so that -std=gnu++0x is used.

I'll test that fix tonight if noone beats me to it.

The problem seems to be present on the 4.4 branch as well as trunk.


-- 

jwakely dot gcc at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely dot gcc at gmail dot
                   |                            |com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

------- Comment #3 from redi at gcc dot gnu dot org  2009-08-10 15:09 -------
For now, the workaround is to provide some or all of these explicit
instantiations in your program:

namespace std
{
    template
    basic_ofstream<char>::basic_ofstream(string const&, ios_base::openmode);

    template
    void 
    basic_ofstream<char>::open(string const&, ios_base::openmode);

    template
    basic_ifstream<char>::basic_ifstream(string const&, ios_base::openmode);

    template
    void 
    basic_ifstream<char>::open(string const&, ios_base::openmode);

    template
    basic_fstream<char>::basic_fstream(string const&, ios_base::openmode);

    template
    void 
    basic_fstream<char>::open(string const&, ios_base::openmode);

    template
    basic_filebuf<char>*
    basic_filebuf<char>::open(string const&, ios_base::openmode);
}


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.4.1 4.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-10 15:09:05
               date|                            |
            Summary|Unable to link fstream open |[C++0x] Unable to link
                   |and ctor with std::string   |fstream open and ctor with
                   |argument.                   |std::string argument.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[3dw4rd at verizon dot net]

------- Comment #4 from 3dw4rd at verizon dot net  2009-08-10 19:35 -------
(In reply to comment #2)
> Since the C++0x changes to fstream are only additions, the simplest solution is
> probably to compile src/fstream-inst.cc in c++0x mode, which just means adding
> new targets to src/Makefile.am so that -std=gnu++0x is used.
> 
> I'll test that fix tonight if noone beats me to it.
> 
> The problem seems to be present on the 4.4 branch as well as trunk.
> 

I'm confused because the definitions of these functions are in the header
include/std/fstream.  I thought that inclusion of the header with the
-std=c++0x flag would get the definition or that if PCH is used, at least one
would have been compiled with -std=gnu++0x and provide the definition.

I would have thought ODR would prevent having the definition here and in
src/fstream-inst.cc.

Or are you saying we should either:
1) move definition open(std::string) etc. to src/fstream-inst.cc (or maybe
better src/fstream-inst_c++0x.cc to be consistent with other treatments).
2) move definition open(std::string) etc. to src/fstream-inst_c++0x.cc
   AND
   move definition open(const char *) etc. to src/fstream-inst.cc
   for consistency


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

------- Comment #5 from jwakely dot gcc at gmail dot com  2009-08-10 19:39 -------
The definitions are in that header, but the 'extern template' extension is used
to prevent the compiler from instantiating the code in your program, see
http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html

Instead of instantiating that code in every object a single explicit
instantiation is provided in libstdc++.so, that's the purpose of
src/fstream-inst.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

------- Comment #6 from jwakely dot gcc at gmail dot com  2009-08-10 20:05 -------
(In reply to comment #5)
> Instead of instantiating that code in every object a single explicit
> instantiation is provided in libstdc++.so, that's the purpose of
> src/fstream-inst.cc

... but in this case it fails to provide an explicit instantiation of the new
C++0x members because src/fstream-inst.cc is not compiled with -std=c++0x or
-std=gnu++0x

So the library tells the compiler not to instantiate the templates in your
code, promising to provide explicit instantiations, and then fails to provide
the explicit instantiations. So the workaround I gave in comment #3 provides
them in your program.  Another workaround would be to compile with
-D_GLIBCXX_EXTERN_TEMPLATE=0, which disables the extern template feature,
causing the compiler to implicitly instantiate the templates in every file that
needs them, and then rely on the linker to merge the duplicate definitions.

But the right fix is just to ensure src/fstream-inst.cc is compiled in C++0x
mode, so that the instantiations are present in libstdc++.so and you don't need
any workaround.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

------- Comment #7 from jwakely dot gcc at gmail dot com  2009-08-11 23:02 -------
This patch (and running autoreconf) fixes the problem, but I'm still trying to
work out the right changes to the linker script so that the new symbols are
versioned as GLIBCXX_3.4.13 not GLIBCXX_3.4

Index: src/Makefile.am
===================================================================
--- src/Makefile.am     (revision 150635)
+++ src/Makefile.am     (working copy)
@@ -278,6 +278,11 @@ atomic.lo: atomic.cc
 atomic.o: atomic.cc
        $(CXXCOMPILE) -std=gnu++0x -c $<

+fstream-inst.lo: fstream-inst.cc
+       $(LTCXXCOMPILE) -std=gnu++0x -c $<
+fstream-inst.o: fstream-inst.cc
+       $(CXXCOMPILE) -std=gnu++0x -c $<
+
 string-inst.lo: string-inst.cc
        $(LTCXXCOMPILE) -std=gnu++0x -c $<
 string-inst.o: string-inst.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[jwakely dot gcc at gmail dot com]

------- Comment #8 from jwakely dot gcc at gmail dot com  2009-08-12 08:55 -------
Created an attachment (id=18344)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18344&action=view)
compile fstream-inst.cc as c++0x to instantiate new members

i'm testing this patch


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |redi at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-08-10 15:09:05         |2009-08-12 08:57:39
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

------- Comment #9 from redi at gcc dot gnu dot org  2009-08-26 19:03 -------
Subject: Bug 41005

Author: redi
Date: Wed Aug 26 19:03:24 2009
New Revision: 151126

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151126
Log:
2009-08-26  Jonathan Wakely  <jwakely.gcc@gmail.com>

        PR libstdc++/41005
        * configure.ac: Bump libtool_VERSION to 6:14:0.
        * configure: Regenerate.
        * src/Makefile.am: Compile fstream-inst.cc as C++0x.
        * src/Makefile.in: Regenerate.
        * config/abi/pre/gnu.ver: Add new symbols and disambiguate old ones,
        move <future> symbols to 3.4.14 version.
        * testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.14 version.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/abi/pre/gnu.ver
    trunk/libstdc++-v3/configure
    trunk/libstdc++-v3/configure.ac
    trunk/libstdc++-v3/src/Makefile.am
    trunk/libstdc++-v3/src/Makefile.in
    trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

------- Comment #10 from redi at gcc dot gnu dot org  2009-08-26 19:04 -------
Subject: Bug 41005

Author: redi
Date: Wed Aug 26 19:04:11 2009
New Revision: 151127

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151127
Log:
2009-08-26  Jonathan Wakely  <jwakely.gcc@gmail.com>

        PR libstdc++/41005
        * configure.ac: Bump libtool_VERSION to 6:13:0.
        * configure: Regenerate.
        * src/Makefile.am: Compile fstream-inst.cc as C++0x.
        * src/Makefile.in: Regenerate.
        * config/abi/pre/gnu.ver: Add new symbols and disambiguate old ones.
        * testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.13 version.

Modified:
    branches/gcc-4_4-branch/libstdc++-v3/ChangeLog
    branches/gcc-4_4-branch/libstdc++-v3/config/abi/pre/gnu.ver
    branches/gcc-4_4-branch/libstdc++-v3/configure
    branches/gcc-4_4-branch/libstdc++-v3/configure.ac
    branches/gcc-4_4-branch/libstdc++-v3/src/Makefile.am
    branches/gcc-4_4-branch/libstdc++-v3/src/Makefile.in
    branches/gcc-4_4-branch/libstdc++-v3/testsuite/util/testsuite_abi.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[redi at gcc dot gnu dot org]

------- Comment #11 from redi at gcc dot gnu dot org  2009-08-26 19:15 -------
Fixed for 4.4.2 and 4.5.0


-- 

redi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.4.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005

[Bug libstdc++/41005] [C++0x] Unable to link fstream open and ctor with std::string argument.

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2009-08-26 22:55 -------
Thanks Jon. I would say I'm guilty of this issue. To be fully honest, when Ed
proposed these bits of C++0x, I wasn't particularly excited: ok, can be
actually handy but really, we don't expect surprises either, no hurry to field
test the feature... So, I saw the inlines, the patch was simple, and forgot
about the extern template. That's the story from my point of view, anyway ;)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41005