[Bug target/28701] New: ABI test failures building libstdc++ on a glibc-2.4 based system

[Bug target/28701] New: ABI test failures building libstdc++ on a glibc-2.4 based system

[doko at ubuntu dot com]

Building 4.1.x on powerpc-linux-gnu and sparc-linux-gnu lets the libstdc++ ABI
check fail (log attached); a libstlport4.6 built on a glibc-2.3.6 system cannot
resolve the references to the libstdc++6 built on the glibc-2.4 system.


-- 
           Summary: ABI test failures building libstdc++ on a glibc-2.4
                    based system
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: doko at ubuntu dot com
GCC target triplet: powerpc-linux-gnu sparc-linux-gnu


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

[Bug target/28701] ABI test failures building libstdc++ on a glibc-2.4 based system

[doko at ubuntu dot com]

------- Comment #1 from doko at ubuntu dot com  2006-08-11 22:47 -------
Created an attachment (id=12069)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12069&action=view)
test log


-- 


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

[Bug target/28701] ABI test failures building libstdc++ on a glibc-2.4 based system

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-11 22:50 -------
I think this is a fall out of the 12bit long double changes.


-- 


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker
            Summary|[ 4.1 / 4.2 regression] ABI |[4.1/4.2 regression] ABI
                   |test failures building      |test failures building
                   |libstdc++ on a glibc-2.4    |libstdc++ on a glibc-2.4
                   |based system                |based system
   Target Milestone|---                         |4.1.2


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2006-08-17 12:38 -------
The is just the libstdc++ ABI check not being able to understand
tanl@@GLIBCXX_3.4 -> tanl@GLIBCXX_3.4 etc. changes (22 such symbols).
Those are not ABI breakers, all that means is that newly linked programs
won't resolve to these symbols in libstdc++.so (but to libm.so), old
programs and libraries can still use those in libstdc++.so.

But the original bug claims not just abicheck failure, but some other problem
with libstlport.  There are no details though, so those need to be provided
- what exactly cannot be resolved, readelf -Ws dumps, etc.
No ABI-checking utilities I'm using showed any problems after the transition
to TFmode long double.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[doko at ubuntu dot com]

------- Comment #4 from doko at ubuntu dot com  2006-08-23 10:20 -------
I see the problem with stlport 4.6.2:

- stlport is built on a glibc-2.3 based system (using g++-4.0)
- libstdc++/g++-4.1 is built on a glibc-2.4 based system
- building the stlport regression tests using the installed
  stlport and libstdc++:

c++ -pthread -Wall -I/usr/include/stlport -I.   -g  stl_test.o accum1.o
accum2.o adjdiff0.o adjdiff1.o adjdiff2.o adjfind0.o adjfind1.o adjfind2.o
advance.o alg
1.o alg2.o alg3.o alg4.o alg5.o bcompos1.o bcompos2.o bind1st1.o bind1st2.o
bind2nd1.o bind2nd2.o binsert1.o binsert2.o binsrch1.o binsrch2.o bnegate1.o
bnegate
2.o bvec1.o copy1.o copy2.o copy3.o copy4.o copyb.o copyb0.o count0.o count1.o
countif1.o deque1.o divides.o eqlrnge0.o eqlrnge1.o eqlrnge2.o equal0.o
equal1.o 
equal2.o equalto.o fill1.o filln1.o find0.o find1.o findif0.o findif1.o
finsert1.o finsert2.o foreach0.o foreach1.o func1.o func2.o func3.o gener1.o
gener2.o ge
nern1.o genern2.o greateq.o greater.o incl0.o incl1.o incl2.o inplmrg1.o
inplmrg2.o inrprod0.o inrprod1.o inrprod2.o insert1.o insert2.o iota1.o
istmit1.o iter1
.o iter2.o iter3.o iter4.o iterswp0.o iterswp1.o less.o lesseq.o lexcmp1.o
lexcmp2.o list1.o list2.o list3.o list4.o logicand.o logicnot.o logicor.o
lwrbnd1.o l
wrbnd2.o map1.o max1.o max2.o maxelem1.o maxelem2.o memfunptr.o merge0.o
merge1.o merge2.o min1.o min2.o minelem1.o minelem2.o minus.o mismtch0.o
mismtch1.o mis
mtch2.o mkheap0.o mkheap1.o mmap1.o mmap2.o modulus.o mset1.o mset3.o mset4.o
mset5.o negate.o nequal.o nextprm0.o nextprm1.o nextprm2.o nthelem0.o
nthelem1.o n
thelem2.o ostmit.o pair0.o pair1.o pair2.o parsrt0.o parsrt1.o parsrt2.o
parsrtc0.o parsrtc1.o parsrtc2.o partsrt0.o partsum0.o partsum1.o partsum2.o
pheap1.o p
heap2.o plus.o pqueue1.o prevprm0.o prevprm1.o prevprm2.o ptition0.o ptition1.o
ptrbinf1.o ptrbinf2.o ptrunf1.o ptrunf2.o queue1.o rawiter.o remcopy1.o
remcpif1
.o remif1.o remove1.o repcpif1.o replace0.o replace1.o replcpy1.o replif1.o
revbit1.o revbit2.o revcopy1.o reverse1.o reviter1.o reviter2.o rndshuf0.o
rndshuf1.
o rndshuf2.o rotate0.o rotate1.o rotcopy0.o rotcopy1.o search0.o search1.o
search2.o set1.o set2.o setdiff0.o setdiff1.o setdiff2.o setintr0.o setintr1.o
setint
r2.o setsymd0.o setsymd1.o setsymd2.o setunon0.o setunon1.o setunon2.o sort1.o
sort2.o stack1.o stack2.o stblptn0.o stblptn1.o stblsrt1.o stblsrt2.o swap1.o
swp
rnge1.o times.o trnsfrm1.o trnsfrm2.o ucompos1.o ucompos2.o unegate1.o
unegate2.o uniqcpy1.o uniqcpy2.o unique1.o unique2.o uprbnd1.o uprbnd2.o vec1.o
vec2.o ve
c3.o vec4.o vec5.o vec6.o vec7.o vec8.o hmmap1.o hset2.o hmset1.o slist1.o
hmap1.o string1.o bitset1.o  -lstlport_gcc -lm  -o stl_test.exe
stl_test.o: In function `main':
/home/doko/tmp/stlport4.6-4.6.2/test/regression/stl_test.cpp:493: undefined
reference to `string_mt_test(int, char**)'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `log10l@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `expl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `cosl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `sinhl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `sqrtl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `coshl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `logl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `sinl@GLIBCXX_3.4'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to `atan2l@GLIBCXX_3.4'
collect2: ld returned 1 exit status
make: *** [stl_test.out] Error 1

I've put the subdirectory including the stlport shared libraries at
http://people.ubuntu.com/~doko/stlport-regresssion-dir.tar.bz2


-- 

doko at ubuntu dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[mmitchel at gcc dot gnu dot org]

------- Comment #5 from mmitchel at gcc dot gnu dot org  2006-09-01 21:51 -------
This is a P1 because we need to understand if there is actually ABI breakage.

If there isn't, or if we can't confirm that there is, we'll downgrade this.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2006-09-04 11:28 -------
Can you
readelf -Ws libstdc++.so.6 | egrep 'l@+GLIBCXX' | grep -v ' _Z'
on both libraries (the 4.0 built one and 4.1.x --with-long-double-128 one)?
The 4.0.x built one should contain the (DFmode) long double *l functions as
*l@@GLIBCXX_3.4* symbols while 4.1.x --with-long-double-128 (note, this
is something that to my knowledge is only as a patch for 4.1 or on
redhat/gcc-4_1-branch, not in stock 4.1, but in stock 4.2) those should be
*l@GLIBCXX_3.4*.  If that's the same on your system as on mine, then the only
reason why you'd get such errors would be a buggy linker.  I have tested
several
linkers (several years old as well as the most recent ones) and they all behave
properly.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2006-09-04 12:14 -------
I have downloaded your tarball and it seems you are not building gcc to default
to 128-bit long double on a glibc 2.4+ system.  That's very bad idea,
you either shouldn't have upgraded to glibc 2.4+, or should have switched
everything to 128-bit long double.
While --with-long-double-128 libstdc++.so.6 is ABI compatible with older one,
--without-long-double-128 exact ABI of the math stubs depends on whatever
configure tests find out.  With older glibc's, log10l etc. is not in system
libm (long double was just 64-bit there and so log10 did the same), but with
glibc 2.4+ it is present in libm (and implements the 128bit long double
logarithm etc.).
Guess something like:
--- libstdc++-v3/src/compatibility.cc   2006-02-23 09:55:01.000000000 +0100
+++ libstdc++-v3/src/compatibility.cc   2006-09-04 14:12:07.000000000 +0200
@@ -398,7 +398,11 @@ GLIBCXX_3.4)
 #undef _List_node_base

 // gcc-4.1.0
-#ifdef _GLIBCXX_LONG_DOUBLE_COMPAT
+#if defined _GLIBCXX_LONG_DOUBLE_COMPAT \
+    || (defined (__GLIBC__) \
+       && (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 4)) \
+       && defined __LONG_DOUBLE_MATH_OPTIONAL \
+       && defined __NO_LONG_DOUBLE_MATH)
 #define _GLIBCXX_MATHL_WRAPPER(name, argdecl, args, ver) \
 extern "C" double                                              \
 __ ## name ## l_wrapper argdecl                                        \
in GCC 4.2 and similar thing, but with also the whole _GLIBCXX_MATHL_WRAPPER
and its uses hunks added in GCC 4.1 could cure this (but that doesn't make it a
good idea to mix glibc 2.4+ with DFmode GCC).


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-09-04 12:14:13
               date|                            |


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[debian-gcc at lists dot debian dot org]

------- Comment #8 from debian-gcc at lists dot debian dot org  2006-10-04 17:36 -------
configuring --with-long-double-128 works. could --with-long-double-128 become
the default, if glibc-2.4 is detected?

the situation reminds me at --enable-__cxa_atexit, which is not the default,
but at least the default in all linux distributions.


-- 


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2006-10-04 22:03 -------
--with-long-double-128 is the default on glibc 2.4+, but only in GCC 4.2.
In vanilla GCC 4.1.x --with-long-double-128 isn't supported at all, those
changes
were added pretty late in the GCC 4.1 devel cycle and so do exist just as
a separate patch (or on redhat/gcc-4_1-branch or ibm/gcc-4_1-branch).


-- 


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[debian-gcc at lists dot debian dot org]

------- Comment #10 from debian-gcc at lists dot debian dot org  2006-10-05 15:13 -------
are other patches than r111381 (trunk) required for a backport of
long-double-128
to the 4.1 branch?

  Matthias


-- 


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

[Bug target/28701] [4.1/4.2 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-10-05 15:40 -------
This looks related to PR 26926.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |26926
              nThis|                            |


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

[Bug target/28701] [4.1/4.2/4.3 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.1.2                       |4.1.3


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

[Bug target/28701] [4.1/4.2/4.3 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

[mmitchel at gcc dot gnu dot org]

------- Comment #12 from mmitchel at gcc dot gnu dot org  2007-03-12 18:31 -------
It appears from the audit trail that there is no GCC bug here, other than,
perhaps, the configuration options not defaulting to ideal choices.  If that's
a problem, file a new PR; however, AFAICT, we do not have a P1 ABI failure
here.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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