lib_path for libjava in top level

lib_path for libjava in top level

[Aaron W. LaFramboise]

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?

Re: lib_path for libjava in top level

[Andrew Haley]

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.