Re: build ideas
I'm all for a way to compile the .class files without the shared libraries. I develop on a cygwin platform, which does not have the best support for free VMs or for shared libraries, so I tend to just compile the java files. By the way, I think developers should have the autotools installed on their machine, so I see no reason for CVS to keep track of generated files like configure and Makefile.in, only the originals like Makefile.am. The generated files should be part of the distribution, though, since end users should not be required to have all the developer tools just to use the final product. Fortunately, automake does this correctly. Who knows, improving the build framework might inspire someone to improve the dependency tracking that jikes does, to make that part of compilation even more efficient and compatible with automake. Brian Jones wrote: > > Like other GNU projects, I would like to continue to use the > automake/autoconf system for driving the compilation of Classpath. > For releases I'd like to continue to distribute compiled .class files > and generated JNI headers. I want CVS builds to generate JNI headers > and .class files relying only on free software. There exists a need > within our community to generate .class files without compiling native > libraries and I'd like that to be easier... it seems to me that to be > successful this must be faster than 'jikes -d /tmp `find java gnu > vm/reference -regex ".*\.java$"` or some working equivalent. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
build ideas
I'm seeking suggestions or ideas from individuals about how they would like to be able to build Classpath. I guess two cases exist, building from CVS and building from a release. I'll start the discussion with my suggestions but I'm hoping for others and some concensus at the end. Like other GNU projects, I would like to continue to use the automake/autoconf system for driving the compilation of Classpath. For releases I'd like to continue to distribute compiled .class files and generated JNI headers. I want CVS builds to generate JNI headers and .class files relying only on free software. There exists a need within our community to generate .class files without compiling native libraries and I'd like that to be easier... it seems to me that to be successful this must be faster than 'jikes -d /tmp `find java gnu vm/reference -regex ".*\.java$"` or some working equivalent. Additions? Contrary notions? Devil's advocate? Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Andreas Rueckert wrote: >>Not necessarily. Any paths seen by ld (e.g. with -L) will not be >>automatically searched by the loader (assuming an ELF target). >> >>So each lib directory must be one of the "system" lib dirs or mentioned in >>LD_LIBRARY_PATH, unless you also link with -rpath. >> > >All these libs are in /etc/ld.so.conf , so it should work. > Nope. The path to the libraries must be in LD_LIBRARY_PATH. I believe this is a limitation of dlopen or maybe libtool's ltdl. >Is there any way to >get additional info what lib is missing? > Classpath's reference runtime implementation should throw the missing library name with the UnsatisfiedLinkError. For some reason your stack trace didnt mention it. Which VM is this? >I honestly think that Classpath is ridiculously complex to install. I guess >you're doing a great job, but as it is, noone will notice. Have you ever >thought of creating RPMs for popular Linux distros, or so? > Here is the build procedure I use to get a classpath suitable for use with ORP: 1. create gnu/classpath/Configuration.java by hand, from gnu/classpath/Configuration.in 2. mkdir build 3. javac -d build -classpath .:build `find java gnu vm -name "*.java"` 4. cp gnu/java/locale/*.uni build/gnu/java/locale/ 5. cp gnu/java/locale/*.properties build/gnu/java/locale/ I admit that this doesn't help if you want the native libraries, however. The lack of an easy-to-use configure/build is a known problem, and we'd love it if someone were to help fix it. regards Bryce. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Hi! On Mon, 15 Okt 2001 Jeff Sturm wrote: > On Mon, 15 Oct 2001, Andreas Rueckert wrote: > > It seems everything is there. But shouldn't the compile of the Gtk peer lib > > fail anyway, if one of the libs is missing? > > Not necessarily. Any paths seen by ld (e.g. with -L) will not be > automatically searched by the loader (assuming an ELF target). > > So each lib directory must be one of the "system" lib dirs or mentioned in > LD_LIBRARY_PATH, unless you also link with -rpath. All these libs are in /etc/ld.so.conf , so it should work. Is there any way to get additional info what lib is missing? I honestly think that Classpath is ridiculously complex to install. I guess you're doing a great job, but as it is, noone will notice. Have you ever thought of creating RPMs for popular Linux distros, or so? Ciao, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
