ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juan Jimenez" <>
Subject Re: UnsatisfiedLinkError when invoking native library from junit task
Date Wed, 14 Jun 2006 13:51:37 GMT
Thank you for taking an interest.

Our tests have always been forked and I do want to avoid hacks, which is why
I am coming to this forum.

This is what I have so far ( lib.package contains all shared objects ):

<property name="junit.lib.path" value="${java.library.path}${path.separator
}${lib.package}" />
<junit failureproperty="junit.failed"

        <path refid="test.classpath"/>

    <!-- we now reset java.library.path to something specific to this
project -->
    <sysproperty key="java.library.path" path="${junit.lib.path}"/>

         However, it doesn't seem to work under Linux.  Native libraries
         by Java are loaded correctly but other native libraries needed by
         native libraries loaded by Java cannot be found

         None of the following worked (aside from not being platform

    <sysproperty key="LD_LIBRARY_PATH" path="${junit.lib.path}"/>
    <env key="LD_LIBRARY_PATH" path="${junit.lib.path}" />
    <env key="LD_LIBRARY_PATH" path="${env.LD_LIBRARY_PATH}${path.separator
}${lib.package}" />
    <env key="LD_LIBRARY_PATH" path="${env.LD_LIBRARY_PATH}${path.separator
}${lib.package}" />

    the following also works on Windows if you also remove the sysproperty
above, however this
    is not platform independent and should be avoided
    <env key="PATH" path="${junit.lib.path}" />

    <formatter type="xml"/>
    <formatter type="plain"/>

    <batchtest todir="${testresults.dir}">
        <fileset dir="${src.test}">
            <include name="**/*Test*.java"/>


On 14/06/06, Dominique Devienne <> wrote:
> > Presumably you are running <junit> forked? I think you also need to make
> > sure that your path and library search path includes the existing env
> > variables.
> Mostly likely not. The only "right" solution is to <junit fork="true">.
> > > Am I going to be forced to look into a nominated directory and preload
> > > anything that matches *.so before invoking a non-forked JVM for the
> unit
> > > tests?
> That would be a hack, and even then you'd have to load them in the
> proper dependency order. I had a too-clever colleague use such an
> approach to work around a similar issue in WebStart, but it's very
> brittle, and very hacky.
> It's not a matter of using LoadLibraryEx or not, since *nix in general
> does not allow you to alter the library loading path of an existing
> process.
> So just fork your tests ;-) --DD
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message