On Wed, May 30, 2007 at 08:09:25AM +0200, Paolo Bonzini wrote:
Gcj isn't available for compile-and-link test when building libjava.
I found a solution, which is to add a ltgcc.m4 file to the toplevel,
where we can override macros as we wish. For example, you can put a
copy of the Java
On Wed, May 30, 2007 at 04:17:28PM +0200, Paolo Bonzini wrote:
H. J. Lu wrote:
On Wed, May 30, 2007 at 08:09:25AM +0200, Paolo Bonzini wrote:
Gcj isn't available for compile-and-link test when building libjava.
I found a solution, which is to add a ltgcc.m4 file to the toplevel,
where we can
On Tue, May 29, 2007 at 09:07:49AM +0200, Paolo Bonzini wrote:
This patch allows me to run aclocal and autoconf. However, it still
doesn't work. But we can't use conftest* as Java class file name since
it will be removed after a test is done. That means the second gcj
test will fail since
On Tue, May 29, 2007 at 06:47:07AM -0700, H. J. Lu wrote:
On Tue, May 29, 2007 at 09:07:49AM +0200, Paolo Bonzini wrote:
This patch allows me to run aclocal and autoconf. However, it still
doesn't work. But we can't use conftest* as Java class file name since
it will be removed after
On Tue, May 29, 2007 at 04:21:22PM +0200, Paolo Bonzini wrote:
It doesn't work since gcj isn't functional at that time. configure
complains
configure:16060: /export/build/gnu/gcc-isa/build-x86_64-linux/gcc/gcj
On Tue, May 29, 2007 at 04:49:11PM +0200, Paolo Bonzini wrote:
Certainly. Any compile-and-link tests won't work.
I'm sorry, I missed the and link part of your question. Configury
tests of this kind really aren't going to work. For things like tests
for PIC, it's pointless: gcj
On Tue, May 29, 2007 at 07:33:28PM -0400, [EMAIL PROTECTED] wrote:
On Tue, 29 May 2007 12:36:13 -0600, Tom Tromey
said:
Charles == Charles Wilson writes:
Charles Secondly, the entire contents of libjava/libltdl/ need to be
Charles updated.
I don't think we need to do this. libgcj
On Mon, May 28, 2007 at 11:53:50AM +0200, Paolo Bonzini wrote:
As I understand the theory (compile .class files instead of .java files)
this is fine with me. However, being curious about the portability of
the awk expression, I tried it on solaris, there with both awk and nawk,
printf %c,0;
On Mon, May 28, 2007 at 03:58:29PM +0200, Andreas Schwab wrote:
H. J. Lu [EMAIL PROTECTED] writes:
bash-3.1$ cd libjava
bash-3.1$ autoconf
/usr/bin/m4:configure.ac:450: ERROR: recursion limit of 1024 exceeded, use
-LN to change it
autom4te: /usr/bin/m4 failed with exit status: 1
On Thu, Sep 23, 2004 at 03:35:25PM -0700, H. J. Lu wrote:
On Thu, Sep 23, 2004 at 02:46:14AM +0100, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi H.J,
On 7 Sep 2004, at 21:11, H. J. Lu wrote:
I don't understand why libtool
has to put the install
On Thu, Sep 23, 2004 at 02:46:14AM +0100, Gary V. Vaughan wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi H.J,
On 7 Sep 2004, at 21:11, H. J. Lu wrote:
I don't understand why libtool
has to put the install directory in RPATH for compile. Removing it
shouldn't cause any problem
On Fri, Sep 03, 2004 at 03:12:59PM -0700, H. J. Lu wrote:
On Fri, Sep 03, 2004 at 01:51:34PM -0700, H. J. Lu wrote:
The newly built libgcc_s.so.1 may not be used for make check. It
leads to 2 problems:
1. The newly built libgcc_s.so.1 may be fully tested by make check.
2. Those tests
On Fri, Sep 03, 2004 at 01:51:34PM -0700, H. J. Lu wrote:
The newly built libgcc_s.so.1 may not be used for make check. It
leads to 2 problems:
1. The newly built libgcc_s.so.1 may be fully tested by make check.
2. Those tests which won't work with old libgcc_s.so.1 may fail.
This patch
Libtool has been driving me nuts. I tried to cross compile a package which
uses libtool. For some reason, libtool wanted libgdbm.so from /usr/lib:
/bin/sh ../libtool --mode=link mipsel-linux-gcc -Wall -W -O2 -mips2 -fPIC -o
libsasl.la -rpath /usr/lib -version-info 8:8:1 common.lo saslutil.lo
On Thu, Feb 07, 2002 at 05:34:55AM -0200, Alexandre Oliva wrote:
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
# gcc -fPIC -c foo.c
# ar rcs libfoo.a foo.o
# gcc -fPIC -c bar.c
# gcc -shared -o libar.so bar.o -lfoo -L.
I don't want ANY dependency of libfoo.a in libbar.so
On Thu, Feb 07, 2002 at 10:57:57AM -0600, Robert Boehne wrote:
Alexandre:
You have my approval to un-do my mistsake. If I had understood
exactly what this patch was doing then I would have rejected it myself.
H.J. As I now understand it, your patch doesn't improve anything,
it just breaks
On Thu, Feb 07, 2002 at 05:55:27PM -0200, Alexandre Oliva wrote:
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
Well, there is no libiberty.so. You wind up with always linking files
in libiberty.a when libtool is used, no matter they are needed or
not.
And what is the problem
On Thu, Feb 07, 2002 at 03:10:07AM -0200, Alexandre Oliva wrote:
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
* libtool.m4 (lt_cv_deplibs_check_method
On Thu, Feb 07, 2002 at 04:27:15AM -0200, Alexandre Oliva wrote:
On Feb 7, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
Please read my original message again.
Please read my original reply again.
# gcc -fPIC -c foo.c
# ar rcs libfoo.a foo.o
# gcc -fPIC -c bar.c
# gcc -shared -o
On Mon, Feb 04, 2002 at 09:52:04AM -0200, Alexandre Oliva wrote:
On Feb 4, 2002, H . J . Lu [EMAIL PROTECTED] wrote:
* libtool.m4 (lt_cv_deplibs_check_method): Support Linux/mips.
Before I waste any further time on it, is it any different from the
patch I rejected some months ago
This is a patch for libtool to support Linux/mips. Unlike Linux/i386,
we get
# file /lib/libc-2.2.4.so
/lib/libc-2.2.4.so: ELF 32-bit LSB mips-1 shared object, MIPS R3000_LE [bfd bug],
version 1, not stripped
on Linux/mips. This patch tries to support Linux/mips. Also we don't
need to set
Does libtool really support cross compile? Libtool should never, ever set
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
when generating binaries for the cross target. The current libtool in gcc
3.x does it wrong. I am enclosing a patch for ltconfig here. I don't know
how to fix libtool.
in /lib, /usr/lib or /usr/local/lib yet.
H.J.
Es schrieb H . J . Lu:
Does libtool really support cross compile? Libtool should never, ever set
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
when generating binaries for the cross target. The current libtool in gcc
3.x does
On Wed, Oct 31, 2001 at 09:18:35PM +0100, Guido Draheim wrote:
Hmm, I just checked the sources of libtool - and it seems you are
absolutly correct - there is nothing that will try to detect crosscompiling
automatically and kill the native's libpath, possibly filling it with the
one being
On Tue, Oct 23, 2001 at 11:24:42AM -0500, Robert Boehne wrote:
Hello,
Here is the patch reworked for HEAD. If noone objects
I'll commit it.
ChangeLog Entry:
2001-10-23 H.J. Lu [EMAIL PROTECTED]
* ltmain.sh: Allow link against an archive when building a
shared
Here is a patch for binutils to fix linking against an archive when
building a shared library. It is complete bogus to put
dependency_libs='-L. -lfoo
in *.la for libfoo.a when building a shared library. I checked out
libtool from CVS. But libtool.m4 is very different from the one
in
It is very stupid for libtool.m4 to break other Linux platforms just
because Linux/ARM is different. Here is a patch for Linux/mips.
However, the correct fix should be
case $host_cpu in
arm*)
# Handle ARM differently.
;;
*)
On Sat, Mar 11, 2000 at 07:46:05PM -0300, Alexandre Oliva wrote:
On Mar 10, 2000, "H . J . Lu" [EMAIL PROTECTED] wrote:
1. The new gcc calls collect2.
2. collect2 calls ld/ld-new.
3. ld/ld-new uses the new gcc to relink the new ld.
No. It's using the old GCC, but it is
28 matches
Mail list logo
