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

2006-10-05 Thread 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

2006-10-05 Thread 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 regression] ABI test failures building libstdc++ on a glibc-2.4 based system

2006-10-04 Thread 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

2006-10-04 Thread 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

2006-09-04 Thread 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 '[EMAIL PROTECTED]' | 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
[EMAIL PROTECTED]  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

2006-09-04 Thread 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.0 +0100
+++ libstdc++-v3/src/compatibility.cc   2006-09-04 14:12:07.0 +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|-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

2006-09-01 Thread 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

2006-08-23 Thread 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 [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../lib/libstlport_gcc.so:
undefined reference to [EMAIL PROTECTED]'
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

2006-08-17 Thread 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 - [EMAIL PROTECTED] 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

2006-08-13 Thread 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