With this simple build file: ---- <project name="t" default="doit" basedir="."> <target name="doit"> <echo message="${java.library.path}"/> </target> </project> ---- ant echoes an empty string. With Java code, the property prints out properly. The same build file on a CentOS system, a Windows system, an Ubuntu system, and others, outputs the property value as expected. As java was updated, I told myself that maybe this required that I remerged ant again, so I did emerge $(qlist -I -C dev-java/ant). But no luck, the result is the same. My JAVA_HOME and JDK_HOME are set properly (via the eselect command): fg@erwin ~ $ readlink -f $JAVA_HOME /opt/sun-jdk-1.6.0.16 fg@erwin ~ $ readlink -f $JDK_HOME /opt/sun-jdk-1.6.0.16 Reproducible: Always Steps to Reproduce: 1. Copy the build file above onto your system, in a directory, under the name build.xml 2. Install ant if not done already (no need for ant-nodeps, just core ant) 3. Run ant Actual Results: As I said, the build file echoes an empty string, while Java code prints out the property fine: ---- fg@erwin ~ $ cat t.java public final class t { public static void main (String[] args) { System.out.println(System.getProperty("java.library.path")); } } fg@erwin ~ $ javac t.java; java t /opt/sun-jdk-1.6.0.16/jre/lib/amd64/server:/opt/sun-jdk-1.6.0.16/jre/lib/amd64:/opt/sun-jdk-1.6.0.16/jre/../lib/amd64:/usr/java/packages/lib/amd64:/lib:/usr/lib fg@erwin ~ $ cat build.xml; ant <project name="t" default="doit" basedir="."> <target name="doit"> <echo message="${java.library.path}"/> </target> </project> Buildfile: build.xml doit: [echo] BUILD SUCCESSFUL Total time: 0 seconds ---- Expected Results: The build file should echo the same thing as the Java code. It does so on at least 4 other systems that I tested it to. I have two gentoo installations, both suffer from this problem.
I should add that other system properties show up correctly: os.name, os.arch, for instance, are not a problem.
As mentioned in bug 125563, our launchers (general gjl and ant also) set library path only from packages' package.env, which overrides the JVM default. Since we store the JVM default also in its env file, maybe we should append it then?
(In reply to comment #2) > As mentioned in bug 125563, our launchers (general gjl and ant also) set > library path only from packages' package.env, which overrides the JVM default. > Since we store the JVM default also in its env file, maybe we should append it > then? > While we're at it, I work on qt-jambi, which relies on java.library.path to look for libs. When it tries to copy libstdc++.so, it fails, since it is in the current gcc compiler path and not shown in java.library.path either. I didn't look at the launchers, but I came up with that scriptlet which does show the libstdc++ path: ---- which gcc &>/dev/null if [ "$?" != "0" ]; then echo >&2 "gcc not found! Cannot continue" exit 1 fi ALL="$(gcc -print-search-dirs | grep "^libraries:")" ALL=${ALL#*=} ALL="$LD_LIBRARY_PATH:$ALL" echo $ALL | sed 's,:,\n,g' | while read dir; do # # Some paths may not exist # if [ ! -d $dir ]; then continue fi D=$( (cd $dir && pwd -P) ) echo $D done | sort | uniq ----
Old version gone. Closing.