This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: lib_path for libjava in top level
- From: Andrew Haley <aph at redhat dot com>
- To: "Aaron W. LaFramboise" <aaronavay62 at aaronwl dot com>
- Cc: java at gcc dot gnu dot org
- Date: Sun, 24 Aug 2008 11:49:48 +0100
- Subject: Re: lib_path for libjava in top level
- References: <48B074AF.2030707@aaronwl.com>
Aaron W. LaFramboise wrote:
> Presently in the top-level Makefile.def, libjava is not among the
> libraries that have a specified TARGET_LIB_PATH. For libraries that
> have this, such as libgcc, libgomp, libstdc++, and others, it ensures
> that RPATH is set appropriately when in-tree executables are run as part
> of the build or test process. For instance:
>
> target_modules = { module= libgomp; lib_path=.libs; };
>
> Because on this, on i386-pc-mingw32, gcj-dbtool.exe fails to run when
> libgcj is compiled as a dynamic library, if there is not already a
> binary-compatible libgcj installed on the system somewhere that the
> loader can find it.
>
> Is this an oversight, or there some other mechanism that is supposed to
> make this work, that perhaps doesn't work on Windows?
Libtool is supposed to fix this. gcj-dbtool in the build dir is a shell
script that generates the executable .libs/lt-gcj-dbtool and then executes it.
lt-gcj-dbtool has an rpath-link pointing into the build dir.
Maybe libtool doesn't work properly on mingw.
Andrew.