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.tmp 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
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
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
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: 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: 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: 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(VERSION)
AC_SUBST(JEMACS_VERSION)
AC_SUBST(SHELL)
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
