Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
* Torsten Werner [EMAIL PROTECTED] [2007-04-20 13:31]: * alpha: Running the unit tests: cd build/test/unit obj/gcc/so/stl_unit_test /bin/sh: line 1: 7948 Segmentation fault obj/gcc/so/stl_unit_test Maybe Falk can take a look. * arm: c++ -pthread -fexceptions -fident -O2 -g -fuse-cxa-atexit -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I../../../stlport -c -o obj/gcc/so/ptrspec_test.o ../../../test/unit/ptrspec_test.cpp c++: Internal error: Segmentation fault (program as) I'll start a compilation on ARM soon, but apparently it takes about 5-6 hours. ../../../test/unit/list_test.cpp(392) : CPPUNIT_ASSERT(lint1.size() == 20); Do you have any evidence that this is a gcc bug rather than one in your package? * s390: c++ -pthread -fexceptions -fident -O2 -g -fuse-cxa-atexit -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I../../../stlport -c -o obj/gcc/so/string_test.o ../../../test/unit/string_test.cpp ../../../stlport/stl/char_traits.h: In member function 'void StringTest::constructor()': ../../../stlport/stl/char_traits.h:236: internal compiler error: in s390_expand_setmem, at config/s390/s390.c:3559 I've finally reduced this and reported it upstream a few days ago. The S/390 GCC people from IBM are usually pretty quick with bug fixes. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
* Martin Michlmayr [EMAIL PROTECTED] [2007-04-23 13:21]: I've finally reduced this and reported it upstream a few days ago. The S/390 GCC people from IBM are usually pretty quick with bug fixes. In fact, they just sent the following response: In your example the memset function is called with -1 as length argument. When GCC tries to expand this as a builtin function an assertion in the s390 back end function s390_expand_setmem is triggered. Although an ICE is the wrong thing to respond I would consider it a code bug as well. I've proposed a patch to issue a proper error message and call the library function in that situation. The library function probably would write one byte below the target address causing a segfault for a -1 length which is most likely not what the programmer intended but thats what would happen in the -O0 as well. This is response to a reduced example based on the preprocessed source from stlport5.1's string_test.cpp which you can find at http://gcc.gnu.org/bugzilla/attachment.cgi?id=13392action=view -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
* Martin Michlmayr [EMAIL PROTECTED] [2007-04-23 13:21]: * arm: c++ -pthread -fexceptions -fident -O2 -g -fuse-cxa-atexit -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I../../../stlport -c -o obj/gcc/so/ptrspec_test.o ../../../test/unit/ptrspec_test.cpp c++: Internal error: Segmentation fault (program as) I'll start a compilation on ARM soon, but apparently it takes about 5-6 hours. Builds fine here, so I guess the official auto builder might have run out of memory. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
Martin Michlmayr [EMAIL PROTECTED] writes: * Torsten Werner [EMAIL PROTECTED] [2007-04-20 13:31]: * alpha: Running the unit tests: cd build/test/unit obj/gcc/so/stl_unit_test /bin/sh: line 1: 7948 Segmentation fault obj/gcc/so/stl_unit_test Maybe Falk can take a look. With all this tangled C++ source, it is extremely difficult for me to make a test case. If somebody who is more familiar with the package produces a simpler test case, I'm willing to look into it. -- Falk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
On Tuesday 29 August 2006 00:04, Torsten Werner wrote: Package: g++-4.1 Version: 4.1.1-11 Severity: important Hello, after upgrading g++-4.1 and libstdc++6-4.1-dev from version 4.1.1-5 to version 4.1.1-11 the package stlport5.1 fails to build from source on i386. I am attaching a full build log. The failing unit test can be found at about 65% of the file. The error is currently ignored when building the package otherwise I would have been unable to upload it. The upstream author is quite sure that the error is somewhere in our build environment. Please see https://sourceforge.net/tracker/?func=detailatid=766246aid=1546905group_id=146814 for a longer discussion. Regards, Torsten Hi, Well, really I treat this as question to package maintainers of gcc: I know only about 'official' releases of gcc. 'Official' bash-3.1$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/opt/gcc-4.1.1 --libexecdir=/usr/local/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ Thread model: posix gcc version 4.1.1 give me correct results. Then see the difference between 4.1.1-5 and 4.1.1-11: this is package maintainer's area. Here you say about 4.1.1-*, but in attached log I see c++ (GCC) 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)... Ah, wonderful mystification! Masquerade 4.1.2 prerelease (build from current gcc SVN?) by 4.1.1-11! I think this is question to gcc team before release happens. One more question to you: c++ -pthread -fexceptions -fident -O2 -g -fuse-cxa-atexit -D_REENTRANT -I../../../stlport -c -o I see you made modification of build: -O2 -g both in force, while I prefer either -O2 (release-shared) or -g (dbg-shared) or -g -D_STLP_DEBUG (stldbg-shared). Check what say variant without optimization, and, may be, _STLP_DEBUG mode. I'm suspect optimization first. Good luck, - ptr -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (986, 'testing'), (985, 'stable'), (87, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.27 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages g++-4.1 depends on: ii gcc-4.1 4.1.1-11 The GNU C compiler ii gcc-4.1-base 4.1.1-11 The GNU Compiler Collection (base ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libstdc++6-4.1-dev4.1.1-11 The GNU Standard C++ Library v3 (d g++-4.1 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
Petr Ovtchenkov writes: Well, really I treat this as question to package maintainers of gcc: I know only about 'official' releases of gcc. 'Official' bash-3.1$ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1.1/configure --prefix=/opt/gcc-4.1.1 --libexecdir=/usr/local/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ Thread model: posix gcc version 4.1.1 give me correct results. Then see the difference between 4.1.1-5 and 4.1.1-11: this is package maintainer's area. so what did you test, the upstream release, -5, and -11? Just to be sure, that/if 4.1.1-5 works. Here you say about 4.1.1-*, but in attached log I see c++ (GCC) 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)... Ah, wonderful mystification! Masquerade 4.1.2 prerelease (build from current gcc SVN?) by 4.1.1-11! I think this is question to gcc team before release happens. there's nothing masqueraded, as you see in the gcc version number, which includes the package version as well. The changes are mentioned in the changelog as well. surely you can upload a new upstream tarball to the archives each time now that we have the possibility to use version numbers like 4.1.2~20060814-11, but that would be just a duplocated orig.tar.gz. One more question to you: c++ -pthread -fexceptions -fident -O2 -g -fuse-cxa-atexit -D_REENTRANT -I../../../stlport -c -o I see you made modification of build: -O2 -g both in force, while I prefer either -O2 (release-shared) or -g (dbg-shared) or -g -D_STLP_DEBUG (stldbg-shared). it's Debian policy to build with -O2 -g. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385066: stlport5.1_5.0.99rc2-3_i386 FTBFS with g++-4.1 from unstable
Torsten Werner writes: Package: g++-4.1 Version: 4.1.1-11 Severity: important Hello, after upgrading g++-4.1 and libstdc++6-4.1-dev from version 4.1.1-5 to version 4.1.1-11 the package stlport5.1 fails to build from source on i386. I am attaching a full build log. The failing unit test can be found at about 65% of the file. The error is currently ignored when building the package otherwise I would have been unable to upload it. The upstream author is quite sure that the error is somewhere in our build environment. Please see https://sourceforge.net/tracker/?func=detailatid=766246aid=1546905group_id=146814 for a longer discussion. please could you recheck with the current gcc-snapshot package? does lowering the optimization level helps? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
