[Bug libstdc++/11074] libstdc++ fails to build due to gettext issue
--- Comment #18 from tim dot vanholder at anubex dot com 2008-12-26 18:06 --- I see that my gcc build tree (last used to build 4.3.2 on Sep 26) does not have any local changes to the libstdc++-v3 directory, according to 'svn diff'. This at least suggests it is resolved. A quick check shows that abi_check is now built by dejagnu (abi.exp), not the Makefile, and that seems to work. I don't know if the somewhat underlying issue of g++ not automatically linking with libintl & libiconv is resolved; but libstdc++'s testsuite does seem to run properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11074
[Bug testsuite/37622] New: gcc.dg: failure reported for direct2s.c
Clean build from a source tree that was the result of svn switching to the
4.3.2 release tag (was previously a 4.3.0 release I think).
make check reports a handful of errors; I'm logging each separately once I
determine the likely cause.
the gcc.dg/cpp/direct2s.c test fails with "test for excess errors".
The message is "warning: current file is older than direct2.c".
I suspect that it was an error to duplicate the
#pragma GCC dependency "direct2.c"
line from direct2.c instead of changing it to
#pragma GCC dependency "direct2s.c"
Of course this problem would only be triggered if direct2s.c is older than
direct2.c, which is unlikely to happen except as the result of a svn up/switch.
--
Summary: gcc.dg: failure reported for direct2s.c
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim dot vanholder at anubex dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37622
[Bug testsuite/37623] New: builtin-math-4 tests fail
Clean build from a source tree that was the result of svn switching to the 4.3.2 release tag (was previously a 4.3.0 release I think). make check reports a handful of errors; I'm logging each separately once I determine the likely cause. The builtin-math-4.c test (8 flavours) from gcc.dg fails. Lots of linker errors for link_error in the log (which looks like the expected failure type for the testcase). Notable is all flavours except the -O0 one have linker errors other than the intentional link_error ones. In particular, the gamma_r, gammal_r, gammaf_r end up being undefined, so it looks like some not-always-builtin math routines are also included in the test. I'll attach the error list for the test that uses -g, as there the line numbers of the link errors are included. -- Summary: builtin-math-4 tests fail Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim dot vanholder at anubex dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #1 from tim dot vanholder at anubex dot com 2008-09-23 13:45 --- Created an attachment (id=16394) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16394&action=view) Test results for "builtin-math-4.c -O3 -g" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #4 from tim dot vanholder at anubex dot com 2008-09-24 07:03 --- Then perhaps either configure should reject the too-old version, or the testcase should detect this situation and either skip the tests in question and/or report that MPFR is too old. The situation as it stands is not very helpful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug libmudflap/33064] libmudflap fails to build with --enable-targets=all
--- Comment #1 from tim dot vanholder at anubex dot com 2008-02-25 12:37 --- Created an attachment (id=15223) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15223&action=view) Trivial Patch Encountered this same problem today on the 4.3 branch (rev 132620). This is a trivial patch that allows the build to continue (by using __mf_uintptr_t instead of uintptr_t in the .c file, to match the header). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33064
[Bug java/35367] New: Linux x86 build (with --enable-targets=all, so also building with cross-to-x64 multilib configuration) fails in libjava (prims.cc)
configured by ../../../src/gcc/configure, generated by GNU Autoconf 2.59,
with options " '-v' '--prefix=/opt/experimental' '--enable-shared'
'--with-system-zlib' '--enable-threads=posix' '--enable-nls'
'--enable-clocale=gnu' '--enable-libstdcxx-debug' '--enable-libffi'
'--enable-objc-gc' '--enable-mpfr' '--enable-targets=all'
'--enable-checking=release'
'--enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang'"
system: Debian linux (lenny/sid; building gcc myself because I'm stuck with
kernel 2.4 so am unable to install newer debian packages)
libtool: compile: /home/tim/gnu/build/linux/gcc/./gcc/xgcc -shared-libgcc
-B/home/tim/gnu/build/linux/gcc/./gcc -nostdinc++
-L/home/tim/gnu/build/linux/gcc/i686-pc-linux-gnu/64/libstdc++-v3/src
-L/home/tim/gnu/build/linux/gcc/i686-pc-linux-gnu/64/libstdc++-v3/src/.libs
-B/opt/experimental/i686-pc-linux-gnu/bin/
-B/opt/experimental/i686-pc-linux-gnu/lib/ -isystem
/opt/experimental/i686-pc-linux-gnu/include -isystem
/opt/experimental/i686-pc-linux-gnu/sys-include -m64 -DHAVE_CONFIG_H -I.
-I../../../../../../src/gcc/libjava -I./include -I./gcj
-I../../../../../../src/gcc/libjava -Iinclude
-I../../../../../../src/gcc/libjava/include
-I../../../../../../src/gcc/libjava/classpath/include -Iclasspath/include
-I../../../../../../src/gcc/libjava/classpath/native/fdlibm
-I../../../../../../src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../../../../src/gcc/libjava/libltdl
-I../../../../../../src/gcc/libjava/libltdl
-I../../../../../../src/gcc/libjava/.././libjava/../gcc
-I../../../../../../src/gcc/libjava/../zlib
-I../../../../../../src/gcc/libjava/../libffi/include -I../libffi/include
-fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall
-D_GNU_SOURCE -DPREFIX=\"/opt/experimental\"
-DTOOLEXECLIBDIR=\"/opt/experimental/lib/../lib64\"
-DJAVA_HOME=\"/opt/experimental\"
-DBOOT_CLASS_PATH=\"/opt/experimental/share/java/libgcj-4.3.0.jar\"
-DJAVA_EXT_DIRS=\"/opt/experimental/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/opt/experimental/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/opt/experimental/lib/../lib64/gcj-4.3.0-9\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/opt/experimental/lib/../lib64/gcj-4.3.0-9/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.0/classmap.db\" -g -O2
-D_GNU_SOURCE -m64 -MT prims.lo -MD -MP -MF .deps/prims.Tpo -c
../../../../../../src/gcc/libjava/prims.cc -fPIC -DPIC -o .libs/prims.o
../../../../../../src/gcc/libjava/prims.cc: In function 'void
_Jv_catch_fpe(int, siginfo_t*, void*)':
../../../../../../src/gcc/libjava/prims.cc:193: error: cast from 'unsigned
char*' to 'greg_t' loses precision
This seems to be a bug in the configury, as java-signal.h is linked to
i386-signal.h instead of x86_64-signal.h in i686-pc-linux-gnu/64/libjava.
Adjusting that link is not enough to make the build succeed (it still gives the
same error, with additional errors about REG_RIP/RAX/RDX not being declared).
--
Summary: Linux x86 build (with --enable-targets=all, so also
building with cross-to-x64 multilib configuration) fails
in libjava (prims.cc)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim dot vanholder at anubex dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35367
[Bug libgomp/32193] Upgrading GNU/Linux to libc6_2.6~20070518-2 breaks libgomp make - FIX given
--- Comment #5 from tim dot vanholder at anubex dot com 2008-03-03 12:03 --- This issue with pthread_getaffinity_np also occurs on i686 debian, when building with --enable-targets=all (to get 64-bit output support). I have kernel 2.4, with glibc 2.3.6 (can't upgrade due to hardware that is not supported in kernel 2.6). The 32-bit build works, but the 64-bit one fails; the 64-bit config.log doesn't seem to test for the function at all and simply assumes it's there (similar to http://gcc.gnu.org/ml/gcc/2007-04/msg00884.html). It's beginning to look as if --enable-targets=all is quite broken on i686 (so far, issues seen in libmudflap (bug #33064 - 6 months old, with a trivial fix) , libgomp (this one) and libjava (bug #35367, presumed configury issue, much like this one). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32193
[Bug java/26688] New: Classpath Makefiles assume CVS source control
The makefiles for classpath, as included in the libjava tree, run find to
gather lists of specific files (for META-INF etc). The matched files are then
copied to the build tree.
However, the command lines used for the find invocations specifically mention
'CVS' as a directory to exclude; since gcc has switched to subversion, '.svn'
should be excluded instead.
I /think/ this only impacts the list of files in the build tree, and as such is
fairly trivial, but I suppose the files may end up being included in some jar
file too.
--
Summary: Classpath Makefiles assume CVS source control
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tim dot vanholder at anubex dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26688
[Bug libstdc++/11074] libstdc++ fails to build due to gettext issue
--- Additional Comments From tim dot vanholder at anubex dot com 2005-04-20 08:14 --- This is still present. I've now patched acinclude.m4 to detect the library properly (will add as attachment); it's not ideal but it seems to work. Also, like I feared, it introduces a dependency on libintl.so when building C++ programs - and g++ does not know to add libintl when linking. As a result, failures are reported by autoconf tests that check whether the compiler can produce executables. Because of the latter, either gcc needs to duplicate some of the libstdc++ configury so that it can add -lintl (and -liconv where applicable) to its g++ link (and this seems a less-than-optimal thing to do), or libstdc++ needs to improve its i18n checks (ideally using the regular gettext macros, and perhaps rejecting any solution that requires extra libraries). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11074
[Bug bootstrap/19468] gcc+binutils combined fails bootstrap
--- Additional Comments From tim dot vanholder at anubex dot com 2005-01-17 07:17 --- (In reply to comment #1) > This is a dup of bug 11074. The problem is related to how the build is picking up the wrong headers. > > *** This bug has been marked as a duplicate of 11074 *** Actually, it's not really a duplicate of bug 11074 at all, although they have the same symptoms. In this case, all the right configury is in place, but the binutils makefiles don't always specify @INTLLIBS@ when linking. In 11074, adding @INTLLIBS@ is pointless because it also lacks the gettext macros that would normally provide @[EMAIL PROTECTED] In any case, it is not a gcc bug, but a binutils one - it's their Makefiles that are broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19468
[Bug libstdc++/11074] libstdc++ fails to build due to gettext issue
--- Additional Comments From tim dot vanholder at anubex dot com 2004-11-16 07:56 --- (In reply to comment #11) > --disable-nls doesn't kill the build, but it does give extra fails in > 22_locale > for the messages facet. This is expected. Maybe so, but I never used --disable-nls, so whether or not fails are expected is pretty much irrelevant. > I'll close this next week unless somebody can tell me what the problem is. The problem is that the configury assumes that because glibc is present, it can simply include libintl.h and uses of gettext will Just Work(tm). However, on my system, gettext is installed separately alongside glibc, which means that libintl.h defines gettext as a macro that calls the library function libintl_gettext() (so that the libintl version, and not the glibc version, gets linked in). As a result, linking of abi_check fails because libintl_gettext is not found. I would expect something similar to happen if the included gettext is used, as that would also add the libintl_ prefix to avoid using the system's gettext(). It's not a _huge_ problem (it's easy enough to manually add -lintl to abi_check's link line in the makefile) but I would have expected it to be resolved quite a bit quicker, given the near-trivial fix. Come to think of it, because using the gnu locale implementation in this case adds a dependency of libstdc++ on libintl, g++ may need to use -lintl when linking programs (and if it did, that would also fix the libstdc++ build, as abi_check would link properly). So that is probably the better fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11074
