[Bug libstdc++/28811] New: undefined versioned symbol name _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4

[Bug libstdc++/28811] New: undefined versioned symbol name _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4

[pluto at agmk dot net]

i've configured my gcc with -with-pic option and trying
to build statically linked shared c++ library.

$ make
g++ -O2 -g0 -Wall -z defs test.cpp -o libtest.so -fPIC -shared \
                -nodefaultlibs \
                -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic \
                -lc -lgcc_eh
/usr/bin/ld: libtest.so: undefined versioned symbol name
_ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status


-- 
           Summary: undefined versioned symbol name
                    _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GL
                    IBCXX_3.4
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pluto at agmk dot net
 GCC build triplet: x86-64-linux
  GCC host triplet: x86-64-linux
GCC target triplet: x86-64-linux


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

[Bug libstdc++/28811] undefined versioned symbol name _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4

[pluto at agmk dot net]

------- Comment #1 from pluto at agmk dot net  2006-08-22 20:29 -------
Created an attachment (id=12113)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12113&action=view)
makefile for testcase


-- 


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

[Bug libstdc++/28811] undefined versioned symbol name _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4

[pluto at agmk dot net]

------- Comment #2 from pluto at agmk dot net  2006-08-22 20:30 -------
Created an attachment (id=12114)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12114&action=view)
testcase


-- 


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

[Bug libstdc++/28811] undefined versioned symbol name _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-08-22 20:35 -------
How sure are you that this is not a binutils bug?


-- 


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

[Bug libstdc++/28811] undefined versioned symbol name _ZNKSt14basic_ifstreamIcSt11char_traitsIcEE7is_openEv@GLIBCXX_3.4

[hjl at lucon dot org]

------- Comment #4 from hjl at lucon dot org  2006-08-22 21:39 -------
libstdc++ doesn't supports building PIC archive properly. The archive
shouldn't include symbol version even if it is compiled with PIC since symbol
version info is generated by linker when building a shared library.

In glibc, we use -DSHARED to indicate if a file is compiled for shared library.
We need to change ./src/compatibility.cc from

#if defined(_GLIBCXX_SYMVER_GNU) && defined(PIC)

to

#if defined(_GLIBCXX_SYMVER_GNU) && defined(SHARED)

and define -DSHARED when compiling for shared library.


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-08-27 04:55 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-08-27 04:55:05
               date|                            |


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[pluto at agmk dot net]

------- Comment #6 from pluto at agmk dot net  2006-09-08 12:48 -------
any idea how to fix this? i can test proposals.


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[cnstar9988 at gmail dot com]

------- Comment #7 from cnstar9988 at gmail dot com  2007-09-07 05:58 -------
gcc 4.2.1 have the bug too.


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[paolo dot carlini at oracle dot com]

------- Comment #8 from paolo dot carlini at oracle dot com  2008-06-06 11:56 -------
HJ, are you willing to prepare and test a patch? Many thanks in advance.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2008-06-06 12:01 -------
Apparently, this issue has to do essentially with compatibility.cc, and I'd
like to hear its main author...


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2008-06-06 12:14 -------
Doesn't --with-pic build just one set of *.o files?  If yes, then you are out
of luck, either configure libstdc++ without symbol versioning, or you need to
use
a version script when linking --with-pic libstdc++.a statically.
If no and --with-pic builds everything twice and it is possible to compile
the *.o's intended for libstdc++.so with -DSHARED, then surely replacing
uses of #ifdef PIC with #ifdef SHARED is the way to go.
Or leave compatibility.o from libstdc++.a (not sure if it is easily doable
with libtool).


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[hjl dot tools at gmail dot com]

------- Comment #11 from hjl dot tools at gmail dot com  2008-06-06 13:26 -------
Alan checked in a linker patch:

http://sourceware.org/ml/binutils/2008-06/msg00041.html

to specify a file in archive. Is that possible to exclude a file in
archive?


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at bigpond dot net
                   |                            |dot au


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[hjl dot tools at gmail dot com]

------- Comment #12 from hjl dot tools at gmail dot com  2008-06-08 15:45 -------
(In reply to comment #8)
> HJ, are you willing to prepare and test a patch? Many thanks in advance.
> 

Sorry, I may not have time for it in the near future.


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[pluto at agmk dot net]

------- Comment #13 from pluto at agmk dot net  2008-11-14 00:32 -------
(In reply to comment #10)

> If no and --with-pic builds everything twice and it is possible to compile
> the *.o's intended for libstdc++.so with -DSHARED,

i thought about something like this:

$ cat makefile
SRCS := test.cpp
all: libtest.so libtest.a
libtest.so: $(SRCS:.cpp=.os)
        g++ -shared -o $@ $<
libtest.a: $(SRCS:.cpp=.o)
        ar cr $@ $<
%.os: %.cpp
        g++ -c -fpic -DSHARED -o $@ $<
%.o: %.cpp
        g++ -c -fpic -o $@ $<

but i can't transform it into autotools templates :/
i saw that elfutils does such trick within src/makefile.am.


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[bkoz at gcc dot gnu dot org]

------- Comment #14 from bkoz at gcc dot gnu dot org  2009-01-28 01:41 -------
Mine.


-- 

bkoz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-08-27 04:55:05         |2009-01-28 01:41:13
               date|                            |
   Target Milestone|---                         |4.3.4


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[bkoz at gcc dot gnu dot org]

------- Comment #15 from bkoz at gcc dot gnu dot org  2009-01-28 03:25 -------

Here are my thoughts on how to fix this. None of the presented options is
workable, IMHO.

The preferred end goal is to only have the compatibilty.cc and
compatibilty-ldbl.cc objects in the shared library, and not in the static
library.

1) HJ's suggestion in #11, to remove compatibility.cc and compatibility-ldbl.cc
archive files from the static library via binutils trickery. Alan responded
that the capability is limited to removal, but that's what is wanted here. My
preference is to not build the (incorrect) object file in the first place.

2) Adding -DSHARED to LTCXXCOMPILE in src/Makefile.am. This doesn't
disambiguate between shared and static objects though. Out.

3) Custom rules for compatibility.o and compatibility.lo in src/Makefile.am.
the *.lo rule adds -DSHARED and the *.o rule does not. Replace PIC with SHARED
in compatibility.cc
This mostly works, as long as the *.o rule is compiled after the *.lo rule.
Seems weak to rely on this ordering though.

4) somehow stuff the compatibility objects into a separate, shared-library-only
convenience library

?


-- 


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2009-08-04 12:27 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

[Bug libstdc++/28811] --with-pic vs static libraries and libstdc++

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2010-05-22 18:11 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.5                       |4.3.6


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