java.lang.UnsatisfiedLinkError в Linux

У меня есть библиотека, созданная для Linux, и ее можно найти здесь:

/test/lib/liblzo.so

Затем у меня есть следующий код Java:

импортировать org.junit.Test;

public class CompressionTest {

    @Test
    public void testCompression() throws Exception {
        System.out.println("java.library.path=" + System.getProperty("java.library.path"));
        try {
            System.loadLibrary("lzo");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

Выполнение этого приводит к следующему исключению:

CompressionTest > testCompression FAILED
        java.lang.UnsatisfiedLinkError: no lzo in java.library.path
            at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1878)
            at java.lang.Runtime.loadLibrary0(Runtime.java:849)
            at java.lang.System.loadLibrary(System.java:1087)
            at CompressionTest.testCompression(CompressionTest.java:11)

Тем не менее, я вижу из стандарта из теста, что путь к моей библиотеке находится на пути к библиотеке:

java.library.path=/test/lib

Я сократил код до простейшей настройки и до сих пор не могу понять, почему библиотека не загружается. Может ли кто-нибудь посоветовать, что может пойти не так, и как я могу отладить проблему?

Обновить

Вчера я много играл с этим, как уже упоминалось, я очистил все java.library.path для этого поста, но заметил, что он был довольно длинным. Длинный по общей длине, но и то, что каждый каталог на нем был достаточно вложенным (возможны 8/9 уровней). Я сократил путь, включив в него только известный мне каталог, где находится библиотека so, и это сработало.

Кто-нибудь вообще знает о каких-либо ограничениях длины java.library.path?


linux java unsatisfiedlinkerror
person imrichardcole    schedule 03.06.2014    source источник
comment
Пожалуйста, посмотрите мой первый комментарий в посте, он уже так называется.   -  person imrichardcole    schedule 03.06.2014

Ответы (2)


arrow_upward
0
arrow_downward

Вы используете относительный путь к библиотеке, и я подозреваю, что вы обнаружите, что ваш тестовый фреймворк выполняет ваш файл из другого каталога. Подтвердите это, проверив текущий рабочий каталог:

System.out.println("user.dir=" + System.getProperty("user.dir"));

Чтобы исправить это, я предлагаю вам установить java.library.path на абсолютный путь, чтобы эти вещи не имели значения.

person that other guy    schedule 03.06.2014
comment
Извините, мне нужно было изменить путь ради этого поста. Я обновил свой исходный пост, все пути в моей библиотеке абсолютны. - person imrichardcole; 03.06.2014
comment
@imrichardcole Можете ли вы сделать тестовый пример без конфиденциальной информации, чтобы вы могли публиковать фактические сообщения, которые вы получаете? Говоря, что он выводит java.library.path=/test/lib, когда это не усложняет отладку. - person that other guy; 04.06.2014

arrow_upward
0
arrow_downward

Почему бы не поместить liblzo.so в какой-нибудь пакет и не получить его как ресурс? Что-то типа:

getClass().getClassLoader().getResource("package.liblzo.so");

Тогда вам больше не придется беспокоиться о путях

person rekiem87    schedule 03.06.2014