I'm replying back on this branch of the thread so the solution is documented closest to the problem.
Using "env" worked! That is awesome! I really appreciate you answering. I've been using Unix for years, but never stumbled to that feature in the env command. Now, interestingly, if I do not use the -i option of env, then the LD path still gets stomped. However, if I use -i option to exclude previous environment settings, all is happy. This shows that something in the immediate calling environment was causing the problem. To prove this out, I went back to the <exec> tag and tried it with the 'newenvironment="true"' attribute, and that seems to have also worked (I'd guess I never tried that). Anyway, many thanks again! Guerry -----Original Message----- From: Dominique Devienne [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 1:22 PM To: 'Ant Users List' Subject: RE: LD_LIBRARY_PATH problems using Ant to call C++ JNI code First let me just say that it seems you tried everything I could think of, and that defining LD_LIBRARY_PATH in the makefile doesn't work is weird. The only remaining thing you could try is to use the 'env' command. I haven't used Unix for a few years now, but I vaguely remember env can be used to set an env. var. for a program it starts itself, like in: env LD_LIBRARY_PATH=... make test If FreeBSD supports this form of env, then maybe by <exec>ing that from Ant would help (instead of bash -c 'make test')!?!? Somehow I doubt it, given the fact that what you tried was unsuccessful, but it's worth a try. --DD -----Original Message----- From: Guerry Semones [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 12:07 PM To: [EMAIL PROTECTED] Subject: LD_LIBRARY_PATH problems using Ant to call C++ JNI code This one is a bit convoluted to describe. We are running a Freebsd unix environment using Ant to control some building and testing. In the case where we're having problems, Ant is running C++ tests by having the Ant script call "make test" to run the tests. If we can resolve this issue, then our build/test cycle will be fully automated on FreeBSD. We are running: Ant 1.4.1 / JDK 1.3.1 / FreeBSD 4.5-RC The build.xml target is: <target name="test" description="Run all unit tests"> <exec executable="/usr/local/bin/bash" failonerror="true" dir="myDir"> <arg line="-c 'make test'" /> </exec> </target> The LD_LIBRARY_PATH is set in the environment to have the following JNI-required stuff: /usr/local/jdk1.3.1/jre/lib/i386:/usr/local/jdk1.3.1/jre/lib/i386/classi c:/usr/local/jdk1.3.1/jre/lib/i386/native_threads:/usr/local/jdk1.3.1/jr e/lib/i386 To be concise, this is the way things are called, and then I'll state the issue we are having: 1. Invoking "ant test" on the command line 2. Ant calls "make test" 3. Make calls C++ unit test (CppUnit) 4. C++ code uses JNI to call JVM instance <-- LD_LIBRARY_PATH needed 5. JVM instance executes Java bytecode The breakdown occurs at step #4. For some reason, the LD_LIBRARY_PATH is lost from the Ant environment (overwritten?) and Ant returns the following error from the C++ unit test code: [exec] t10MyTest.testThisThing [exec] .Cannot open "/usr/local/jdk1.3.1/jre/lib/i386//libhpi.so".Cannot open "/usr/local/jdk1.3.1/jre/lib/i38 6//libhpi.so".Cannot open "/usr/local/jdk1.3.1/jre/lib/i386//libhpi.so"...............Cannot open "/usr/local/jdk1. 3.1/jre/lib/i386//libhpi.so"F [exec] .Cannot open "/usr/local/jdk1.3.1/jre/lib/i386//libhpi.so"F If the test is executed WITHOUT Ant by using MAKE directly, then the error does NOT occur: 1. Invoking "make test" on the command line 2. Make calls C++ unit test (CppUnit) 3. C++ code uses JNI to call JVM instance 4. JVM instance executes Java bytecode Something in the Ant environment seems to be overwriting the LD_LIBRARY_PATH. I have tried putting the LD_LIBRARY_PATH settings into every conceivable place I could conceive of :-). For example, I've set it in the following places: -- in the shell environment -- as parameters in the Makefile -- as parameters in the Ant shell script that executes Ant -- as an <env> tag in the Ant build script itself -- each of these singly and together and several other convoluted things I've tried.... Any ideas? Thanks in advance! Guerry -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
