Bug 31650 - gcc-4_2-branch uses class that has been removed - breaks make
Summary: gcc-4_2-branch uses class that has been removed - breaks make
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-21 18:23 UTC by Rob
Modified: 2007-06-25 05:34 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2007-04-25 00:47:39


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2007-04-21 18:23:47 UTC
When I type make (after making various fixes to get make to complete) I get this far:

/usr/bin/gcjh -jni -bootclasspath ../lib: -o ../../../../../gcc-4_2-branch/libjava/classpath/include/gnu_java_util_prefs_gconf_GConfNativePeer.h gnu.java.util.prefs.gconf.GConfNativePeer
/usr/bin/gcjh -jni -bootclasspath ../lib: -o ../../../../../gcc-4_2-branch/libjava/classpath/include/gnu_java_net_VMPlainDatagramSocketImpl.h gnu.java.net.VMPlainDatagramSocketImpl
gcjh: gnu.java.net.VMPlainDatagramSocketImpl: no such class
make[5]: *** [../../../../../gcc-4_2-branch/libjava/classpath/include/gnu_java_net_VMPlainDatagramSocketImpl.h] Error 1
make[5]: Leaving directory `/opt/gcc-4_2-build-1/i686-pc-linux-gnu/libjava/classpath/include'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/opt/gcc-4_2-build-1/i686-pc-linux-gnu/libjava/classpath/include'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/opt/gcc-4_2-build-1/i686-pc-linux-gnu/libjava/classpath'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/opt/gcc-4_2-build-1/i686-pc-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/opt/gcc-4_2-build-1'
make: *** [all] Error 2

The reason that make breaks at this point is given here:
http://www.gnu.org/software/classpath/announce/20061211.html

Part of that page says:
Runtime interface changes:
* gnu.java.net.VMPlainDatagramSocketImpl removed.

The gcc-4_2-branch SVN is incorrect to be out of sync with classpath and include things that are removed. This makes it unnecesarily hard to compile and
leaves us to try to patch/fix/alter files to cause make to complete - for a feature that is already removed.

It would be nice if the configure scripts could do a better job of scanning for
what is available and at least warning (better yet fixing!) and suggesting either the means to fix it or sending us to a web page that describes what we must do.


Here is my gcc/xgcc -v

# gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4_2-branch/configure --verbose --enable-languages=c,c++,ada,fortran,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-decimal-float --with-long-double-128 --enable-clocale=gnu --enable-debug --with-stabs --disable-sjlj-exceptions --enable-java-gc=boehm --with-x --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-regen-headers --enable-portable-native-sync --enable-libgcj-debug --enable-libgcj-multifile --with-stabs
Thread model: posix
gcc version 4.2.0 20070413 (prerelease)


The "bug" is a complaint about the main ./configure file (not being "smart" enough to 'know' what lies ahead).

When I run ./configure (the "root/main" configure) with the above options it completes quite quickly and uneventfully. I am running Debian gnu/Linux (stable) and have updated yesterday. I have libgcj.so.70 and "many" other newer packages that the gcc-4_2-branch requires to compile (and the "stable" version of Debian is many versions behind in it's packages).


1): ./configure does not even say what languages it is going to attempt to compile (if I alter the order of the --enable-languages=c,c++,ada,fortran,objc,obj-c++ to [for example] --enable-languages=c,c++,fortran,ada,objc,obj-c++ then it DOES mention which languages that it will be attempting to compile). Regardless of whether the order is presented exactly as the scripts would output it OR whether the order you choose your languages does not "exactly match" the order that the script would output it the script ought to say what languages it will be (attempting to) compile.

2): As mentioned in the bug#1 above, ./configure completes without much trouble or many messages (when I configure with the above options). The build works well and make runs through everything quite fast - until it gets to the libjava part of the compile (_almost_near_the_end_of_all_the_effort_!) (avoiding yelling ;) ). Then the make breaks. Simply fixing it and typing "make" again is not good enough - it won't re-start "cleanly"; you MUST delete (or can rename)
"i686-pc-linux-gnu/libjava" and then type "make" so it re-builds the entire libjava directory from scratch - seldom will it re-build after fixes since it doesn't re-run the sub-configure scripts to check that things are "sane".

3): What is really a pain about the main ./configure script is that it completes and lets you type "make" with NO warnings (until the libjava directory is mostly finished) then a few of the sub-configure scripts complain that you don't have this, that or the other installed (or it is not a new enough version). OF _course_ installing the suggested package then makes new dependencies on other packages being installed with newer versions.

Here is some of the files I had to get to compile with the above options fed to the main ./configure script (and it did NOT even bother to run pkg-config to check and tell me until hours into the compile when a sub-configure script tells you).

-rw-r--r--  1 root root  1321109 Feb 26 11:07 GConf-2.16.1.tar.bz2
-rw-r--r--  1 root root   483363 Apr 20 01:13 atk-1.9.1.tar.bz2
-rw-r--r--  1 root root  2973689 Apr 20 01:31 cairo-1.2.6.tar.gz
-rw-r--r--  1 root root  2925342 Apr 20 01:42 glib-2.12.11.tar.bz2
-rw-r--r--  1 root root 15031543 Apr 20 00:00 gtk+-2.10.11.tar.bz2
-rw-r--r--  1 root root  1356322 Apr 20 01:47 pango-1.16.2.tar.bz2
-rw-r--r--  1 root root   969993 Apr 20 14:21 pkg-config-0.20.tar.gz

I can't "apt-get" these (without modifying /etc/apt/sources.list) since they
are not "stable") but gcc-4_2-branch requires all these bleading edge versions
to compile.

Don't get me wrong. I don't mind getting and installing them ! - My complaint is that the ./configure script should mention (before typing "make") that I need to spend some time upgrading and installing various new versions of packages I already have. I also need to read the docs and google the web to determine what order to install everything in so that each package can ./configure itself with all features available. I found this order worked for me: Cairo, GLib, Pango, ATK, then GTK+.

I (am reasonably certain that I) can fix all this myself so please no one rush to help me. I will post the build-log shortly and put a link on this page to the output of "make -i check".

Just letting the 'powers that be' know that ./configure should check dependancies better and it would be kind if configure could offer a little advice (simply "You need to install 'xyz version 123.21.2' or newer") or point us to a web page that gives detailed instructions.

I am using gnu/Linux as an OS, it would be great if I could simply type "make" and then "make install" (no matter what my ./configure options are). Failing that a warning that the compile can't be completed without doing this that and the other thing would be better than the make breaking when it is nearly finished.

PS: Not angry. I've compiled gcc-4_2-branch a couple of dozen times over the past few months. Just discovered this bug (by adding new ./comfigure options and trying a new OS) and am happy to report it and offer suggestions.

Thanks all for the great compiler. The "C" compiler is what I used to compile my kernel - that is how much I trust gcc-4_2-branch - my system has had no trouble and all the modules work fine.
Comment 1 Tom Tromey 2007-04-25 00:47:39 UTC
I agree this is a buglet in libjava/classpath/include/Makefile.am
One workaround: don't configure with --enable-regen-headers.
Comment 2 Rob 2007-04-29 10:51:31 UTC
Prevously I posted: "I will post the build-log shortly and put a link on this page ..."

I finally got it compiled (using an enormous number of features) and got my best results yet for Java:

                === libjava Summary ===

# of expected passes            7006
# of expected failures          12
# of untested testcases         8
runtest completed at Sun Apr 29 01:23:19 2007


Using _similar_ (but NOT the same) options to compile for Cygwin platform results in an "internal compiler error" (in the start of making library libstdc++-v3), otherwise I would post test results for that platform also.

To see (Java with nearly every option enabled) the results of "make -i check" click here: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01490.html

Thanks for your help, Tom.



Comment 3 Rob 2007-05-03 09:55:20 UTC
Another test results report (4.2.0 20070501 on i686-pc-linux-gnu) is here:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00135.html

Almost every option enabled, almost all tests passed (except dfp, in "C").
Comment 4 Rob 2007-06-25 05:34:45 UTC
Resolving as FIXED. Current tests don't have the problems mentioned in this bug report.


Results for 4.3.0 20070623 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01093.html

=== libjava tests ===
 
Running target unix
WARNING: program timed out.
FAIL:  getlocalvartable run
 
  === libjava Summary ===
 
# of expected passes  2537
# of unexpected  failures 1
# of untested testcases  1