Re: libtool and gcj
Anthony Green wrote: > I've been using a hacked version of libtool to build shared libraries > of java code in with gcj. The one problem I had to work around is > that libtool insists on adding "-DPIC" to the compilation line. gcj's > -D is different from gcc and g++. My hack is to simply strip out the > "-D". However - now my tree contains a mix of java and c code and I > need to use -DPIC with gcc. > How do we change libtool to only use -DPIC where appropriate? Well, the generated libtool script is close - you just need to fix the pic_mode definition that is in the GCJ TAG section. The following kludge seems to solve this problem: mv libtool libtool.tmp && \ sed -e '/BEGIN LIBTOOL TAG CONFIG: GCJ/,/END LIBTOOL TAG CONFIG: GCJ/s/-DPIC/-fPIC/' libtool && chmod +x libtool Of course the real fix involves fixing ltmain.sh, but that goes beyond my ability to peer into the bowels of libtool. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
toner cartridges
VERTEX TECHNOLOGIES -SPECIALS OF THE WEEK ON LASER TONER SUPPLIES AT DISCOUNT PRICES-- ORDER BY PHONE:1-888-288-9043 ORDER BY FAX: 1-888-977-1577 E-MAIL REMOVAL LINE: 1-888-248-4930 UNIVERSITY AND/OR SCHOOL PURCHASE ORDERS WELCOME. (NO CREDIT APPROVAL REQUIRED)A LL OTHER PURCHASE ORDER REQUESTS REQUIRE CREDIT APPROVAL. IF YOUR ORDER IS BY CREDIT CARD PLEASE LEAVE YOUR CREDIT CARD # PLUS EXPIRATION DATE. IF YOUR ORDER IS BY PURCHASE ORDER LEAVE YOUR SHIPPING/BILLING ADDRESSES AND YOUR P.O. NUMBER PAY BY CHECK (C.O.D), CREDIT CARD OR PURCHASE ORDER (NET 30 DAYS). NO CREDIT CARD, NO PROBLEM. WE DO ACCEPT CHECK DRAFT BY PHONE ALL TRADEMARKS AND BRAND NAMES LISTED BELOW ARE PROPERTY OF THE RESPECTIVE HOLDERS AND USED FOR DESCRIPTIVE PURPOSES ONLY. 90 DAY UNLIMITED WARRANTY INCLUDED ON ALL PRODUCTS. NOTE: WE DO NOT CARRY 1) XEROX, BROTHER, PANASONIC, FUJITSU PRODUCTS 2) DESKJETJET/INK JET OR BUBBLE JET CARTRIDGES 3) ANY OFFBRANDS BESIDES THE ONES LISTED BELOW. OUR COMPATIBLE LASER PRINTER TONER CARTRIDGE PRICES AS FOLLOWS: (PLEASE ORDER BY PAGE NUMBER AND/OR ITEM NUMBER) FOR HEWLETT PACKARD: (ON PAGE 2) ITEM #1 LASERJET SERIES 4L,4P (74A)$44 ITEM #2 LASERJET SERIES 1100 (92A)-$44 ITEM #3 LASERJET SERIES 2 (95A)$39 ITEM #4 LASERJET SERIES 2P (75A)---$54 ITEM #5 LASERJET SERIES 5P,6P,5MP, 6MP (3903A)-- -$44 ITEM #6 LASERJET SERIES 5SI, 8000 (09A)$95 ITEM #7 LASERJET SERIES 2100, 2200 (96A)---$74 ITEM #8 LASERJET SERIES 8100 (82X)-$115 ITEM #9 LASERJET SERIES 5L/6L (3906A)--$39 ITEM #10 LASERJET SERIES 4V-$95 ITEM #11 LASERJET SERIES 4000 (27X)--$79 ITEM #12 LASERJET SERIES 3SI/4SI (91A)---$54 ITEM #13 LASERJET SERIES 4, 4M, 5,5M-$49 ITEM #13A LASERJET SERIES 5000 (29X)-$125 ITEM #13B LASERJET SERIES 1200---$59 ITEM #13C LASERJET SERIES 4100---$99 ITEM #18 LASERJET SERIES 3100--$39 ITEM #19 LASERJET SERIES 4500 BLACK--$79 ITEM #20 LASERJET SERIES 4500 COLORS $125 FOR HEWLETT PACKARD FAX (ON PAGE 2) ITEM #14 LASERFAX 500, 700 (FX1)--$49 ITEM #15 LASERFAX 5000,7000 (FX2)$64 ITEM #16 LASERFAX (FX3)--$59 ITEM #17 LASERFAX (FX4)--$54 FOR LEXMARK/IBM (ON PAGE 3) OPTRA 4019, 4029 HIGH YIELD---$89 OPTRA R, 4039, 4049 HIGH YIELD---$105 OPTRA E310.312 HIGH YIELD$79 OPTRA E---$59 OPTRA N--$115 OPTRA S--$165 OPTRA T--$195 OPTRA E310/312---$79 OPTAA E410/412---$89 FOR EPSON (ON PAGE 4) ACTION LASER 7000,7500,8000,9000--$105 ACTION LASER 1000,1500$105 FOR CANON PRINTERS (ON PAGE 5) PLEASE CALL FOR MODELS AND UPDATED PRICES FOR CANON PRINTER CARTRIDGES PANASONIC (0N PAGE 7) NEC SERIES 2 MODELS 90 AND 95--$105 APPLE (0N PAGE 8) LASER WRITER PRO 600 or 16/600--$49 LASER WRITER SELECT 300,320,360-$74 LASER WRITER 300 AND 320$54 LASER WRITER NT, 2NT$54 LASER WRITER 12/640-$79 FOR CANON FAX (ON PAGE 9) LASERCLASS 4000 (FX3)---$59 LASERCLASS 5000,6000,7000 (FX2)-$54 LASERFAX 5000,7000 (FX2)$54 LASERFAX 8500,9000 (FX4)$54 FOR CANON COPIERS (PAGE 10) PC 3, 6RE, 7 AND 11 (A30)-$69 PC 300,320,700,720,760,900,910,920(E-40)--$89 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Sat, Feb 23, 2002 at 08:08:53AM -0800, Anthony Green wrote: > I've been using a hacked version of libtool to build shared libraries of > java code in with gcj. The one problem I had to work around is that > libtool insists on adding "-DPIC" to the compilation line. gcj's -D is > different from gcc and g++. My hack is to simply strip out the "-D". > However - now my tree contains a mix of java and c code and I need to > use -DPIC with gcc. > > How do we change libtool to only use -DPIC where appropriate? This gets added by libtool.m4 here (line 4311): case "$host_os" in # For platforms which do not support PIC, -DPIC is meaningless: *djgpp*) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)= ;; *) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC" ;; esac This seems quite wrong. Why do we assume the compiler will grok -DPIC? Why isn't this handled in the tag-specific and os-specific portions of libtool.m4? If the tag/os combo says -KPIC is needed, why do we -KPIC -DPIC? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
How do I export only specific symbols? What name should I pass to lt_dlopen?
Hello, I am using the current libtool with cygwin 1.3.9 (all packages up to date as of this morning): libtool 20010531a-1 libtool-devel 20020202-1 libtool-devel-src 20020202-1 libtool-stable 1.4.2-2 My project has to run on windows (NT/2000/XP) and Linux (2.4.9) and Solaris (8). Here is the relevant portion of the makefile Makefile.am: [snip] lib_LTLIBRARIES = libsk.la libsk_la_SOURCES = ... libsk_la_LDFLAGS = -no-undefined -export-dynamic -version-info 1:0:0 -module -export-symbols sk.sym [/snip] However, when examining the libsk.dll.a on windows, ALL the symbols are exported! I have yet to see if the patched libtool even works on Linux or Solaris. How do I specify a .def file for windows targets? The .sym seems to make no difference. Thanks in advance! Stephano Mariani ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Specifying a .def file for use with libtools libraries
Yes, I have, and unfortunately, it does not work! I have been looking through the source code of the libtool generated by configure... it seems that it generates an .exp file using the following command: /usr/bin/nm -B .libs/libfile_somefile.o | sed -n -e 's/^.*[ ]\([ABCDGISTW][ABCDGISTW]*\)[ ][ ]*\(_\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* //' | sort | uniq > .libs/libfile.exp And passes it to ld via gcc using -Wl,-retain-symbols-file -Wl,.libs/libfile.exp This seems flawed to me since ld simply ignores it as far as I can see! Stephano Mariani > -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Monday, 18 February 2002 7 14 > To: Stephano Mariani > Cc: [EMAIL PROTECTED] > Subject: Re: Specifying a .def file for use with libtools libraries > > This is kindof a kluge, but try this: > > libname_la_LDFLAGS = foo.def <-no-undefined and other link flags> > > --chuck > > Stephano Mariani wrote: > > > Hello, > > > > Is there a way to use something similar to .def files with libtool. I > > have no way of limiting the export list, and the -export-symbols > > directive in the libname_la_LDFLAGS seems not to work. > > > > I could go and rename all the symbols to avoid conflicts, but I would > > rather not... there has to be a way to do this using libtool. > > > > Please help! I am fast getting desperate enough to drop libtool > > altogether. > > > > Thanks in advance, > > > > Stephano Mariani > > > > > > -- > > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > Bug reporting: http://cygwin.com/bugs.html > > Documentation: http://cygwin.com/docs.html > > FAQ: http://cygwin.com/faq/ > > > > > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: Specifying a .def file for use with libtools libraries
I am using the current libtool-devel (libtool-devel 20020202-1) provided under cygwin (updated this morning 11:?? GMT). I have coded the package from scratch, and libtoolized... I have AC_PREREQ(2.52) in my configure.ac. FYI: I have read the docs, and have been using libtool for a while... just not on windows! Stephano Mariani > -Original Message- > From: Charles Wilson [mailto:[EMAIL PROTECTED]] > Sent: Monday, 18 February 2002 8 12 > To: Stephano Mariani > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Specifying a .def file for use with libtools libraries > > You do know that there are TWO (or more) different versions of libtool > in the cygwin distribution, right? One is based on libtool-1.4.2 and > uses dlltool to generate the DLL. > > The other is based on libtool-cvs(2002-02-02) and uses gcc/ld directly > to build the DLLs. (Note that there are TWO commands to generate DLLs: > "archive_cmds" and "archive_expsym_cmds". Which one is used depends on > a bunch of stuff). > > Finally, there's whatever version of libtool was used in the package you > are working on: most libtoolized packages ship with a ltmain.sh file > already. > > If you didn't explicitly re-libtoolize the package, then you are using > whatever version of libtool the upstream maintainer used. If you DID > explicitly relibtoolize, then you are EITHER using 1.4.2 or 2002-02-02, > depending on what the wrapper script detects from your configure.in/ac file. > > If you didn't understand that (what's all this about wrapper scripts??), > then you REALLY need to read /usr/doc/Cygwin/auto*.README, > /usr/doc/Cygwin/libtool*.README and check out THIS email message: > http://cygwin.com/ml/cygwin-announce/2001/msg00177.html > > Now, which version of libtool are you REALLY using? > > --chuck > > P.S. with respect to the cygwin "devel" libtool, it is a work in > progress. It works for everything *I've* tried so far: "normal" C and > C++ dlls. I haven't attempted to hide symbols (as you are doing) so I > can neither confirm nor deny that it works/breaks. Of course, I don't > know if even the OLD libtool-1.4.2 method *really* allows that, so this > may not be a "regression" per se. Also, Ralf Habacker *previously* > problems wrt KDE DLLs using the 20010531 cygwin "devel" libtool, but I > don't know whether the 20020202 cygwin "devel" libtool fixes those > problems for him. (Again, this is not a regression because 1.4.2 can't > build the KDE DLLs at all, so...) > > Stephano Mariani wrote: > > > Yes, I have, and unfortunately, it does not work! > > > > I have been looking through the source code of the libtool generated by > > configure... it seems that it generates an .exp file using the following > > command: > > > > /usr/bin/nm -B .libs/libfile_somefile.o | sed -n -e 's/^.*[ > > ]\([ABCDGISTW][ABCDGISTW]*\)[ ][ > > ]*\(_\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* //' | sort > > | uniq > .libs/libfile.exp > > > > And passes it to ld via gcc using -Wl,-retain-symbols-file > > -Wl,.libs/libfile.exp > > > > This seems flawed to me since ld simply ignores it as far as I can see! > > > > Stephano Mariani > > > > > >>-Original Message- > >>From: Charles Wilson [mailto:[EMAIL PROTECTED]] > >>Sent: Monday, 18 February 2002 7 14 > >>To: Stephano Mariani > >>Cc: [EMAIL PROTECTED] > >>Subject: Re: Specifying a .def file for use with libtools libraries > >> > >>This is kindof a kluge, but try this: > >> > >>libname_la_LDFLAGS = foo.def <-no-undefined and other link flags> > >> > >>--chuck > >> > >>Stephano Mariani wrote: > >> > >> > >>>Hello, > >>> > >>>Is there a way to use something similar to .def files with libtool. > >>> > > I > > > >>>have no way of limiting the export list, and the -export-symbols > >>> > > > > > >>>directive in the libname_la_LDFLAGS seems not to work. > >>> > >>>I could go and rename all the symbols to avoid conflicts, but I > >>> > > would > > > >>>rather not... there has to be a way to do this using libtool. > >>> > >>>Please help! I am fast getting desperate enough to drop libtool > >>>altogether. > >>> > >>>Thanks in advance, > >>> > >>>Stephano Mariani > >>> > >>> > >>>-- > >>>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > >>>Bug reporting: http://cygwin.com/bugs.html > >>>Documentation: http://cygwin.com/docs.html > >>>FAQ: http://cygwin.com/faq/ > >>> > >>> > >>> > > > > > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Fri, 2002-03-01 at 00:19, Per Bothner wrote: > Of course the real fix involves fixing ltmain.sh, but that goes > beyond my ability to peer into the bowels of libtool. The other bad thing I should mention is the test to see if gcj can use both -c and -o. This test is failing for some unknown reason, causing bad problems for my project. I don't think libtool should even perform this test. gcj is known to always handle -c and -o. I'm using the cvs libtool. I'd really appreciate it if somebody who understands the current implementation could fix these problems. Thanks! AG ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Fri, Mar 01, 2002 at 06:58:08AM -0800, Anthony Green wrote: > On Fri, 2002-03-01 at 00:19, Per Bothner wrote: > > Of course the real fix involves fixing ltmain.sh, but that goes > > beyond my ability to peer into the bowels of libtool. > > The other bad thing I should mention is the test to see if gcj can use > both -c and -o. This test is failing for some unknown reason, causing > bad problems for my project. I don't think libtool should even perform > this test. gcj is known to always handle -c and -o. What version of gcj are you using? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Fri, 2002-03-01 at 07:15, Albert Chin wrote: > What version of gcj are you using? The trunk of the GCC tree (and the 3.1 branch). AG ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
GCJFLAGS
Why does HEAD libtool use GCJFLAGS when autoconf 2.5x doesn't support it? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
On Fri, Mar 01, 2002 at 06:58:08AM -0800, Anthony Green wrote:
> On Fri, 2002-03-01 at 00:19, Per Bothner wrote:
> > Of course the real fix involves fixing ltmain.sh, but that goes
> > beyond my ability to peer into the bowels of libtool.
>
> The other bad thing I should mention is the test to see if gcj can use
> both -c and -o. This test is failing for some unknown reason, causing
> bad problems for my project. I don't think libtool should even perform
> this test. gcj is known to always handle -c and -o.
Try the patch below and let me know if it works. Note this removes
-DPIC completely (even for C, C++).
--
albert chin ([EMAIL PROTECTED])
-- snip snip
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.248
diff -u -3 -p -r1.248 libtool.m4
--- libtool.m4 7 Feb 2002 19:54:36 - 1.248
+++ libtool.m4 1 Mar 2002 17:31:17 -
@@ -832,8 +832,8 @@ AC_CACHE_CHECK([if $compiler supports -c
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"],
[$1],[CXX],[save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -o out/conftest2.$ac_objext"],
- [$1],[GCJ],[save_GCJFLAGS="$GCJFLAGS"
- GCJFLAGS="$GCJFLAGS -o out/conftest2.$ac_objext"])
+ [$1],[GCJ],[save_CFLAGS="$CFLAGS"
+ CFLAGS="$GCJFLAGS -o out/conftest2.$ac_objext"])
echo "$lt_simple_compile_test_code" > conftest.$ac_ext
# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
@@ -856,7 +856,7 @@ AC_CACHE_CHECK([if $compiler supports -c
fi
ifelse([$1],[],[CFLAGS="$save_CFLAGS"],
[$1],[CXX],[CXXFLAGS="$save_CXXFLAGS"],
- [$1],[GCJ],[GCJFLAGS="$save_GCJFLAGS"])
+ [$1],[GCJ],[CFLAGS="$save_CFLAGS"])
chmod u+w .
$rm conftest* out/*
rmdir out
@@ -3155,7 +3158,7 @@ objext=o
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
-lt_simple_compile_test_code="class foo {}"
+lt_simple_compile_test_code="class foo {};"
# Code to be used in simple link tests
lt_simple_link_test_code='public class conftest { public static void main(String[]
argv) {}; }'
@@ -4294,7 +4297,7 @@ AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_co
if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
_LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
-[$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC], [],
+[$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)], [],
[case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in
"" | " "*) ;;
*) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)" ;;
@@ -4302,15 +4305,6 @@ if test -n "$_LT_AC_TAGVAR(lt_prog_compi
[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
_LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no])
fi
-case "$host_os" in
- # For platforms which do not support PIC, -DPIC is meaningless:
- *djgpp*)
-_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
-;;
- *)
-_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)
-DPIC"
-;;
-esac
])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: GCJFLAGS
> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes: Albert> Why does HEAD libtool use GCJFLAGS when autoconf 2.5x doesn't Albert> support it? The support is in automake. Tom ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj
Anthony Green wrote: > The other bad thing I should mention is the test to see if gcj can use > both -c and -o. This test is failing for some unknown reason, causing > bad problems for my project. I don't think libtool should even perform > this test. gcj is known to always handle -c and -o. The reason it is failing is because to compile the test program it uses the value of teh valraivle ac_compile, which is $CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext', and where CC=gcj CFLAGS="-g -O2" CPPFLAGS="". Notice there is no -o option. However, just above, GCJFLAGS is set to include the needed -o flag. So the problem is that ac_compile has the wrong value. In comparison, when we see if g++ supports -c -o, ac_compile has the value: '$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext'. The actula bug is presumably in the definition of AC_LIBTOOL_LANG_GCJ_CONFIG in libtool.m4. The corresponding AC_LIBTOOL_LANG_CXX_CONFIG uses the same AC_LIBTOOL_PROG_CC_C_O($1), but the preamble of AC_LIBTOOL_LANG_CXX_CONFIG is substantially different from AC_LIBTOOL_LANG_GCJ_CONFIG. Specifically, the former sets ac_compile in the comamnds generated by: AC_LANG_PUSH(C++) Unfortuntely, autoconf 2.52 does not define 'Java' as a language. But that can probably be worked around. More later. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GCJFLAGS
On Fri, Mar 01, 2002 at 12:01:24PM -0700, Tom Tromey wrote: > > "Albert" == Albert Chin <[EMAIL PROTECTED]> writes: > > Albert> Why does HEAD libtool use GCJFLAGS when autoconf 2.5x doesn't > Albert> support it? > > The support is in automake. That doesn't help when running autoconf though. Specifically, from libtool.m4: AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext], [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)], [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=no $rm -r conftest 2>/dev/null mkdir conftest cd conftest mkdir out ifelse([$1],[],[save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"], [$1],[CXX],[save_CXXFLAGS="$CXXFLAGS" CXXFLAGS="$CXXFLAGS -o out/conftest2.$ac_objext"], [$1],[GCJ],[save_GCJFLAGS="$GCJFLAGS" GCJFLAGS="$GCJFLAGS -o out/conftest2.$ac_objext"]) echo "$lt_simple_compile_test_code" > conftest.$ac_ext ... ifelse([$1],[],[CFLAGS="$save_CFLAGS"], [$1],[CXX],[CXXFLAGS="$save_CXXFLAGS"], [$1],[GCJ],[GCJFLAGS="$save_GCJFLAGS"]) I've patched this to use CFLAGS in exchange for GCJFLAGS but only when doing tests like the above. GCJFLAGS is still present in Makefile.am. Shouldn't autoconf support gcj natively? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GCJFLAGS
> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes: >> The support is in automake. Albert> That doesn't help when running autoconf though. Specifically, Albert> from libtool.m4: I meant that the variable is set in an autoconf macro that is supplied with automake. Albert> Shouldn't autoconf support gcj natively? Yes. Tom ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool and Solaris
Hello. Please forgive me if this is the wrong place to ask this question, but I didn't know what better place. I'm trying to build several projects from Linux on Solaris. I'm using libtool 1.4 and GCC 2.95.3 on Solaris8. I'm building IMLIB2. When I build it using the Sun linker I get the following behavour: /bin/sh ../libtool --mode=link gcc -g -O2 -L/usr/X11R6/lib -o testfilter.la -rpath /usr/local/lib/loaders/filter -no-undefined -module -avoid-version filter_test.lo rm -fr .libs/testfilter.la .libs/testfilter.* .libs/testfilter.* /usr/ccs/bin/ld -G -z defs -h testfilter.so -o .libs/testfilter.so filter_test.lo -L/usr/X11R6/lib -lc Undefined first referenced symbol in file imlib_create_color_modifier filter_test.lo imlib_free_image_and_decachefilter_test.lo imlib_create_image filter_test.lo imlib_image_fill_rectangle filter_test.lo imlib_context_set_color_modifierfilter_test.lo ld: fatal: Symbol referencing errors. No output written to .libs/testfilter.so The interesting thing is that if I use GNU Binutils on Solaris the library builds with no problems... HOWEVER everything that uses this library compiled via Binutils code dumps on startup (Bus Error). I've removed binutils from my system, grabbed the latest Sun patch for the linker and tried over and over to get past this, but can't. Can anyone help? Any help is _greatly_ appreciated. [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Updated:RE: libtool and Solaris
I found something interesting. For IMLIB2, I'm trying to build the CVS version. There was a previously released version that seems to build fine for me. The big diffrence would be that the released version had configure scripts pre-built, whereas I, on the CVS version, run autoconf, automake, etc myself. The release version compiles fine whereas the CVS version does not. When comparing things I found that the release version sets the libtools "no_undefined_flags" to "-z text" yet when I use the CVS version I get the same variable set to "-z defs". I changed "-z defs" to "-z text" and it builds without error now. Is this a good idea or bad? Whats the diffrence between the two? And why might libtool/configure be setting it this way? [EMAIL PROTECTED] -Original Message- From: Ben Rockwood Sent: Fri 3/1/2002 11:13 AM To: [EMAIL PROTECTED] Cc: Subject:libtool and Solaris Hello. Please forgive me if this is the wrong place to ask this question, but I didn't know what better place. I'm trying to build several projects from Linux on Solaris. I'm using libtool 1.4 and GCC 2.95.3 on Solaris8. I'm building IMLIB2. When I build it using the Sun linker I get the following behavour: /bin/sh ../libtool --mode=link gcc -g -O2 -L/usr/X11R6/lib -o testfilter.la -rpath /usr/local/lib/loaders/filter -no-undefined -module -avoid-version filter_test.lo rm -fr .libs/testfilter.la .libs/testfilter.* .libs/testfilter.* /usr/ccs/bin/ld -G -z defs -h testfilter.so -o .libs/testfilter.so filter_test.lo -L/usr/X11R6/lib -lc Undefined first referenced symbol in file imlib_create_color_modifier filter_test.lo imlib_free_image_and_decachefilter_test.lo imlib_create_image filter_test.lo imlib_image_fill_rectangle filter_test.lo imlib_context_set_color_modifierfilter_test.lo ld: fatal: Symbol referencing errors. No output written to .libs/testfilter.so The interesting thing is that if I use GNU Binutils on Solaris the library builds with no problems... HOWEVER everything that uses this library compiled via Binutils code dumps on startup (Bus Error). I've removed binutils from my system, grabbed the latest Sun patch for the linker and tried over and over to get past this, but can't. Can anyone help? Any help is _greatly_ appreciated. [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj (patch)
This patch to libtool.m4 fixes two problems: (1) Set ac_compile so the proper compiler and flags are used when running tests. (2) Does not set -DPIC is the TAG is GCJ. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ --- libtool.m4~ Thu Feb 28 23:08:04 2002 +++ libtool.m4 Fri Mar 1 12:13:39 2002 @@ -3147,6 +3147,9 @@ # Source file extension for C test sources. ac_ext=java +ac_compile='$GCJ -c $GCJFLAGS conftest.$ac_ext >&AS_MESSAGE_LOG_FD' +ac_link='$GCJ -o conftest$ac_exeext $GCJFLAGS $LDFLAGS conftest.$ac_ext $LIBS +>&AS_MESSAGE_LOG_FD' +ac_compiler_gnu=$ac_cv_gcj_compiler_gnu # Object file extension for compiled C test sources. objext=o @@ -4289,7 +4292,7 @@ if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works], _LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1), -[$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC], [], +[$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[GCJ],[],[ -DPIC])], [], [case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in "" | " "*) ;; *) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=" $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)" ;; @@ -4303,7 +4306,7 @@ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)= ;; *) -_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC" +_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, +$1)ifelse([$1],[GCJ],[],[ -DPIC])" ;; esac ])
Re: libtool and gcj (patch)
On Fri, 2002-03-01 at 12:19, Per Bothner wrote: > This patch to libtool.m4 fixes two problems: > > (1) Set ac_compile so the proper compiler and flags are > used when running tests. Strangely, configure reports that the -c -o test still fails although I'm not seeing the build failure I attributed to the problem anymore. > (2) Does not set -DPIC is the TAG is GCJ. This works perfectly. Thanks! AG ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
No static libraries?
I think this is my final real problem with the CVS version of libtool (once Per's patch is applied). Libtool isn't building static libraries for my project, although it does try to install them (and fail). Configuring with --disable-static is my work around. Any ideas? AG ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj (patch)
On Fri, 2002-03-01 at 12:19, Per Bothner wrote: > (1) Set ac_compile so the proper compiler and flags are > used when running tests. I take what I previously said about this part of the patch back. It doesn't appear to fix anything for me. Is there some other change which is missing? AG ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Fri, Mar 01, 2002 at 02:15:05PM -0800, Anthony Green wrote: > I think this is my final real problem with the CVS version of libtool > (once Per's patch is applied). > > Libtool isn't building static libraries for my project, although it does > try to install them (and fail). You need to be more specific. 1. Does it fail while configuration your application to detect that static libraries can be built? 2. For what compiler (C, C++, GCJ)? A snippet of the ./configure run would help too. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Fri, 2002-03-01 at 15:32, Albert Chin wrote:
> You need to be more specific.
> 1. Does it fail while configuration your application to detect
> that static libraries can be built?
I don't know what you mean exactly.
> 2. For what compiler (C, C++, GCJ)?
GCJ (however, some of the libraries contain C as well).
> A snippet of the ./configure run would help too.
The fact that the gcj -c -o test results in "yes" doesn't mean
anything. I've hacked libtool to always produce that result for gcj.
Thanks for your help!
AG
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking dependency style of gcc... gcc3
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output...
checking whether ln -s works... yes
checking how to recognise dependant libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag works... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
appending configuration tag "GCJ" to libtool
checking if gcj supports -fno-rtti -fno-exceptions... (cached) yes
checking for gcj option to produce PIC... -fPIC
checking if gcj PIC flag -fPIC works... no
checking if gcj supports -c -o file.o... yes
checking whether the gcj linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking for gcj... gcj
checking for gcjh... gcjh
checking dependency style of g++... gcc3
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for libraries needed for readline... -lreadline -ltermcap
configure: creating ./config.status
config.status: creating Makefile
config.status: creating pgsql-jdbc/Makefile
config.status: creating gnu.regexp/Makefile
config.status: creating cup/Makefile
config.status: creating BCEL/Makefile
config.status: creating xerces/Makefile
config.status: creating jakarta-regexp/Makefile
config.status: creating jakarta-oro/Makefile
config.status: creating jakarta-log4j/Makefile
config.status: creating xalan/Makefile
config.status: creating jakarta-servletapi/Makefile
config.status: creating jakarta-tomcat/Makefile
config.status: creating gnu.readline/Makefile
config.status: creating rhino/Makefile
config.status: creating bsf/Makefile
config.status: cre
Re: libtool and gcj
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes: Per> Unfortuntely, autoconf 2.52 does not define 'Java' as a language. Per> But that can probably be worked around. Autoconf 2.52+ would be most happy to support Java. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
gcj libtool patches so far
This combination of Per's -DPIC change and Albert's -c -o change
appears to work best. I've appended it below. The only problem left
is the static library problem previously reported.
Thanks!
AG
2001-03-01 Anthony Green <[EMAIL PROTECTED]>
* libtool.m4 (AC_LIBTOOL_PROG_CC_C_O): Albert Chin's gcj fix.
(AC_LIBTOOL_PROG_COMPILER_PIC): Per Bothner's change for not
using -DPIC with gcj.
Index: libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libtool.m4,v
retrieving revision 1.248
diff -u -p -c -r1.248 libtool.m4
*** libtool.m4 7 Feb 2002 19:54:36 - 1.248
--- libtool.m4 2 Mar 2002 01:13:23 -
*** AC_CACHE_CHECK([if $compiler supports -c
*** 832,839
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"],
[$1],[CXX],[save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -o out/conftest2.$ac_objext"],
! [$1],[GCJ],[save_GCJFLAGS="$GCJFLAGS"
! GCJFLAGS="$GCJFLAGS -o out/conftest2.$ac_objext"])
echo "$lt_simple_compile_test_code" > conftest.$ac_ext
# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
--- 832,839
CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"],
[$1],[CXX],[save_CXXFLAGS="$CXXFLAGS"
CXXFLAGS="$CXXFLAGS -o out/conftest2.$ac_objext"],
! [$1],[GCJ],[save_GCJFLAGS="$CFLAGS"
! CFLAGS="$GCJFLAGS -o out/conftest2.$ac_objext"])
echo "$lt_simple_compile_test_code" > conftest.$ac_ext
# According to Tom Tromey, Ian Lance Taylor reported there are C compilers
*** AC_CACHE_CHECK([if $compiler supports -c
*** 856,862
fi
ifelse([$1],[],[CFLAGS="$save_CFLAGS"],
[$1],[CXX],[CXXFLAGS="$save_CXXFLAGS"],
! [$1],[GCJ],[GCJFLAGS="$save_GCJFLAGS"])
chmod u+w .
$rm conftest* out/*
rmdir out
--- 856,862
fi
ifelse([$1],[],[CFLAGS="$save_CFLAGS"],
[$1],[CXX],[CXXFLAGS="$save_CXXFLAGS"],
! [$1],[GCJ],[CFLAGS="$save_CFLAGS"])
chmod u+w .
$rm conftest* out/*
rmdir out
*** objext=o
*** 3155,3161
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
! lt_simple_compile_test_code="class foo {}"
# Code to be used in simple link tests
lt_simple_link_test_code='public class conftest { public static void main(String[]
argv) {}; }'
--- 3155,3161
_LT_AC_TAGVAR(objext, $1)=$objext
# Code to be used in simple compile tests
! lt_simple_compile_test_code="class foo {};"
# Code to be used in simple link tests
lt_simple_link_test_code='public class conftest { public static void main(String[]
argv) {}; }'
*** AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_co
*** 4294,4300
if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
_LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
! [$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) -DPIC], [],
[case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in
"" | " "*) ;;
*) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)" ;;
--- 4294,4300
if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
_LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
! [$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[GCJ],[],[ -DPIC])], [],
[case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in
"" | " "*) ;;
*) _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="
$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)" ;;
*** case "$host_os" in
*** 4308,4314
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
;;
*)
! _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic,
$1) -DPIC"
;;
esac
])
--- 4308,4314
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
;;
*)
! _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic,
$1)ifelse([$1],[GCJ],[],[ -DPIC])"
;;
esac
])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and gcj (patch)
Anthony Green wrote:
> I take what I previously said about this part of the patch back. It
> doesn't appear to fix anything for me. Is there some other change which
> is missing?
The patch is relative to the libtool.m4 installed into the directory
$prefix/share/aclocal, from CVS libtool, checked-out yesterday.
ltmain.sh is identical to the one in $prefix/share/libtool.
The other lt* files have been deleted. automake is 1.5d, and
autoconf is 2.52h. The configure.in is as in following attachment.
> This combination of Per's -DPIC change and Albert's -c -o change
> appears to work best.
But Albert's patch uses CFLAGS, which does seem to be the wrong thing
to do.
My -DPIC change is of course a kludge. Better would be to have some
langage-specific variable similar to ac_compile, such as
ac_lang_pic_flag.
--
--Per Bothner
[EMAIL PROTECTED] http://www.bothner.com/per/
dnl Process this with autoconf to create configure
AC_INIT(doc/kawa.texi)
AM_MAINTAINER_MODE
AC_CANONICAL_SYSTEM
AM_INIT_AUTOMAKE(kawa, 1.6.98)
AC_PROG_INSTALL
AC_PROG_LN_S
AC_EXEEXT
AC_OBJEXT
dnl AC_ARG_WITH(classpath,[ --with-classpath Path to Java classes],
classpath=$withval, classpath=$$CLASSPATH)
AC_ARG_ENABLE(kawa-frontend,
[ --enable-kawa-frontend Build "kawa" front-end program using readline],
enable_kawa_frontend=$enableval, enable_kawa_frontend=no)
AC_ARG_WITH(gcj,
[ --with-gjc Compile Kawa using GCJ (GNU Compiler for Java)])
AC_ARG_ENABLE(xml,
[ --disable-xml Don't build support for XML processing],
enable_xml=$enableval, enable_xml=yes)
AC_ARG_ENABLE(servlet,
[ --enable-servletBuild support for generating servlets],
enable_servlet=$enableval, enable_servlet=no)
AC_ARG_WITH(java-collections,
[ --with-java-collections Assume Java collections (java.util.List) is available])
AC_ARG_WITH(java-references,
[ --without-java-references Don't use java.lang.ref],
with_java_references=$withval, with_java_references=yes)
AC_ARG_WITH(swing,
[ --with-swingAssume Swing (Java Foundation Classes) is available])
AC_ARG_WITH(awt,
[ --with-awt Assume AWT is available (default on)])
AC_PROG_CC
AC_PROG_CXX
dnl AC_PROG_INSTALL
#AC_PROG_MAKE_SET
# AM_PROG_GCJ isn't good enough, we have to roll our own.
# AC_CHECK_TOOL(GCJ, gcj)
LT_AC_PROG_GCJ
test -z "$GCJ" && AC_MSG_ERROR([no acceptable gcj found in \$PATH])
if test "x${GCJFLAGS-unset}" = xunset; then
GCJFLAGS="-g -O2"
fi
# dnl AC_SUBST(GCJFLAGS)
dnl We must have the absolute path to the build directory.
TOP_BUILDDIR=`pwd`
case ${with_gcj} in
yes)
GCJ_COMPILED_SELECTED=ENABLE_GCJ_COMPILED
GCJ_SELECTED=WITH_GCJ
JAVA=${JAVA-gij}
JAVAC=${JAVAC-"gcj -C"}
AC_PROG_LIBTOOL
# AM_PROG_GCJ isn't good enough, we have to roll our own.
# AC_CHECK_TOOL(GCJ, gcj)
LT_AC_PROG_GCJ
test -z "$GCJ" && AC_MSG_ERROR([no acceptable gcj found in \$PATH])
if test "x${GCJFLAGS-unset}" = xunset; then
GCJFLAGS="-g -O2"
fi
AC_SUBST(GCJFLAGS)
AC_LIBTOOL_GCJ
_AM_DEPENDENCIES(GCJ)
AC_SUBST(LIBTOOL_DEPS)
test "${with_awt}" = "" && with_awt=no
;;
*)
GCJ_COMPILED_SELECTED=DISABLE_GCJ_COMPILED
GCJ_SELECTED=WITHOUT_GCJ
JAVA=${JAVA-java}
JAVAC=${JAVAC-javac}
test "${with_awt}" = "" && with_awt=yes
;;
esac
AM_CONDITIONAL(WITH_GCJ, test "$with_gcj" = "yes")
AM_CONDITIONAL(ENABLE_XML, test "$enable_xml" = "yes")
AM_CONDITIONAL(ENABLE_SERVLET, test "$enable_servlet" = "yes")
AM_CONDITIONAL(WITH_JAVA_REFERENCES, test "$with_java_references" = "yes")
AM_CONDITIONAL(WITH_SWING, test "$with_swing" = "yes")
AM_CONDITIONAL(WITH_AWT, test "$with_awt" = "yes")
AM_CONDITIONAL(ENABLE_KAWA_FRONTEND, test "$enable_kawa_frontend" = "yes")
if test $enable_kawa_frontend = yes ; then
if test "$with_gcj" = yes ; then
kawa_bin="kawa-bin kawa"
else
kawa_bin=kawa
fi
fi
case ${with_java_collections} in
yes)
JAVA_COLLECTIONS_SELECTED=WITH_JAVA_COLLECTIONS
;;
*)
JAVA_COLLECTIONS_SELECTED=WITHOUT_JAVA_COLLECTIONS
;;
esac
case ${with_swing} in
yes)
extra_java='$(java_SWING)'
SWING_SELECTED=WITH_SWING
;;
*)
extra_java=''
SWING_SELECTED=WITHOUT_SWING
;;
esac
case ${with_awt} in
no) AWT_SELECTED=WITHOUT_AWT ;;
*) AWT_SELECTED=WITH_AWT ;;
esac
case ${enable_xml} in
yes) XML_SELECTED=XML_ENABLED ;;
*) XML_SELECTED=XML_DISABLED ;;
esac
JEMACS_VERSION=`echo $VERSION | sed -e 's/^1/0/'`
AC_SUBST(JAVA)
AC_SUBST(JAVAC)
#These don't do anything, because Make-rules can't contain autoconf
#substitutions. Perhaps fix when new automake is out.
#AC_SUBST(GCJ) AC_SUBST(GCJFLAGS)
AC_SUBST(kawa_bin)
AC_SUBST(XML_SELECTED)
AC_SUBST(JAVA_COLLECTIONS_SELECTED)
AC_SUBST(AWT_SELECTED)
AC_SUBST(SWING_SELECTED)
AC_SUBST(GCJ_COMPILED_SELECTED)
AC_SUBST(GCJ_SELECTED)
AC_SUBST(extra_java)
AC_SUBST(TOP_BUILDDIR)
AC_SUBST(CC)
AC_SUBST(CFLAGS)
AC_SUBST(PACKAGE)
AC_SUBST(VER
Re: libtool and gcj
Akim Demaille wrote: >>"Per" == Per Bothner <[EMAIL PROTECTED]> writes: > Per> Unfortuntely, autoconf 2.52 does not define 'Java' as a language. > Per> But that can probably be worked around. > > Autoconf 2.52+ would be most happy to support Java. If it is just a matter of the support to compile java to native using gcj, including needed libtool support, I think it would be relatively straight-forward. That in itself would be quite helpful. But to "support Java" I think we should also support compiling to .class files, installing .jar files, and support using other java compilers besides gcj. I think my Kawa package (http://www.gnu.org/software/kawa/) works mostly the way I think autotool-based Java packages should work. First, it uses a JAVAC variables (defaulted from the environment) to compile .java to .class files. Secondly, it uses the --with-gcj configure variable to decided whether to in addition compile the .java files to native files using gcj. If --with-gcj is specified, then JAVAC defaults to 'gcj -C'. It might make sense to default --with-gcj to true if GCJ is defined or gcj is in the PATH; I don't do either. As a refinement, Kawa compiles multiple.java files in a single compilation to produce a single .o or .lo file, which speeds up compilation and produces slightly better code. I have a separate Makefile.am for each Java source directory (package, in the Java sense), and all .java files in the same directory are compiled as a unit. Perhaps we could start by defining some or all of AC_PROG_GCJ, AC_PROG_JAVAC (the .java->.class compiler), and AC_PROG_JAVA (the Java .class file "interpreter"). Or perhaps there could be a AC_JAVA that subsumes all three? Implementing this seems single, except for the interaction with --with-gcj. -- --Per Bothner [EMAIL PROTECTED] http://www.bothner.com/per/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: No static libraries?
On Mar 1, 2002, Anthony Green <[EMAIL PROTECTED]> wrote:
> Libtool isn't building static libraries for my project, although it does
> try to install them (and fail).
What's the exact failure mode (snipped of the make output)? What does
libtool --features print? What is in the .la file that it's trying to
install?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software EvangelistProfessional serial bug killer
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
