неправильный класс ELF: ELFCLASS32

Я получаю эту ошибку, указывающую на какой-то файл .so при запуске моего приложения на машине Solaris. Однако приложение отлично работает на моем компьютере с Windows. Если я не ошибаюсь, мое приложение ожидает 64-разрядной версии, но у меня есть только 32-разрядная версия файла .so на машине Solaris. Есть ли способ исправить это, чтобы вместо этого использовалась 32-разрядная версия? Я понимаю, что это не имеет ничего общего с байт-кодами, но, вероятно, с JVM. Я пробовал использовать -d32 или -d64, но это не помогло.

ОБНОВИТЬ:

Это точная ошибка:

Exception in thread "main" java.lang.UnsatisfiedLinkError: librvjs11.so: ld.so.1: java: fatal: librvjs11.so: wrong ELF class: ELFCLASS32<br>
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)<br>
    at java.lang.ClassLoader.loadLibrary0(Unknown Source)<br>
    at java.lang.ClassLoader.loadLibrary(Unknown Source)<br>
    at java.lang.Runtime.loadLibrary0(Unknown Source)<br>
    at java.lang.System.loadLibrary(Unknown Source)<br>

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


java jvm 32bit-64bit
person jasonline    schedule 30.05.2011    source источник
comment
Я получаю эту ошибку ... О какой ошибке вы говорите? Публикация сообщения об ошибке поможет людям понять, о чем вы имеете в виду.   -  person Vineet Reynolds    schedule 30.05.2011
comment
@Vineet: jasonline означает неправильную ошибку класса ELF. Если вы когда-либо видели такой, он не содержит много информации - только имя файла. Это действительно означает, что приложение пытается использовать 32-битный двоичный файл в 64-битной среде.   -  person trutheality    schedule 30.05.2011
comment
@trutheality, я знаю, чему это соответствует. Однако важно то, что об этом можно сообщить в контексте UnsatisfiedLinkError. Поэтому, не зная о произошедшем сбое и о файлах, о которых идет речь, будет очень сложно помочь в устранении неполадок. Я бы предложил посмотреть содержимое LD_LIBRARY_PATH, но это было бы самонадеянно.   -  person Vineet Reynolds    schedule 30.05.2011
comment
@Vineet, спасибо за разъяснения.   -  person trutheality    schedule 30.05.2011
comment
@rutheality, пожалуйста. На данный момент ваш ответ может помочь OP выполнить базовое устранение неполадок, но, если не известно, какая библиотека не удалось загрузить, я боюсь, что психической отладки, которую можно сделать, очень мало.   -  person Vineet Reynolds    schedule 30.05.2011

Ответы (2)


arrow_upward
8
arrow_downward

На основании разговора в другом ответе был сделан вывод, что JVM была 64-битный процесс. Это было подтверждено с помощью команды pflags в Solaris.

Очевидно, флаг -d32, переданный JVM, игнорировался. Это было связано с тем, что JVM могла быть 64-битной, и она не могла работать в 32-битном режиме. Поэтому решением может быть установка 32-разрядной версии JVM и ее использование.

person Vineet Reynolds    schedule 30.05.2011

arrow_upward
3
arrow_downward

Я думаю, что происходит то, что ваше приложение использует библиотеку с собственными предварительно скомпилированными двоичными файлами, и это 32-разрядные.

У вас есть варианты: либо получить 64-битную версию двоичных файлов, либо заставить Java работать в 32-битном режиме, что и должно делать -d32. Однако может ли jvm на этой машине работать в 32-битном режиме? Если это невозможно, то -d32 заставит java выплюнуть предупреждение о том, что он не может работать в 32-битном режиме и что он продолжит работу в 64-битном. Вы получаете это предупреждение?

Я занимаюсь этим CW, потому что Vineet делает все возможное.

person Community    schedule 30.05.2011
comment
Я попытался использовать параметр -d32 на машине Solaris, но он не дал никакого эффекта и по-прежнему показывает ту же ошибку. - person jasonline; 30.05.2011
comment
@jasonline, вы можете проверить, правильно ли передан флаг -d32 в JVM; возможно, используя / usr / ucb / ps -auxww. Кроме того, вы также можете проверить, не смешиваются ли 32-битные и 64-битные библиотеки. Странно, если оба флага -d32 и -d64 сообщают одинаковые результаты. - person Vineet Reynolds; 30.05.2011
comment
@vineet: Верно, я использовал / usr / ucb / ps, чтобы увидеть, появляется ли -d32, но на самом деле я его не вижу. Есть идеи, почему? - person jasonline; 30.05.2011
comment
@jasonline, вы используете скрипт, запускающий JVM? Если это так, вы можете отладить этот сценарий. Однако меня бы не слишком беспокоил этот вывод, поскольку я ожидаю, что JVM по умолчанию будет работать в 32-битном режиме. - person Vineet Reynolds; 30.05.2011
comment
Правильно, даже если я не укажу -d32, он должен был работать как 32-разрядное приложение, но я запутался, потому что он дал мне указанную выше ошибку. Я думал, что если ваше приложение работает как 32-битное, оно найдет также 32-битные библиотеки. - person jasonline; 30.05.2011
comment
@jasonline, я думаю, это поможет проверить, является ли JVM 32-битной JVM или нет. Я ожидаю, что JVM в последних версиях Solaris будет поддерживать как 32-битные, так и 64-битные режимы, не требуя отдельного 64-битного дома Java. Что сообщает java -version -d32 и чем отличается вывод java -version -d64? - person Vineet Reynolds; 30.05.2011
comment
@vineet: оба выхода одинаковы, а JVM - 64-разрядная: Java (TM) SE Runtime Environment (сборка 1.6.0_01-b06) Java HotSpot (TM) 64-разрядная серверная виртуальная машина (сборка 1.6.0_01-b06, смешанная Режим) - person jasonline; 30.05.2011
comment
@jasonline, эээ, вы только что заявили, что -d32 также сообщает, что JVM 64-битная. Если да, то это ваша проблема. Возможно, вы захотите узнать, как получить 32-разрядную версию и информация, размещенная здесь, может не относиться к вашей платформе. Я имею в виду это конкретнее - поскольку Solaris имеет как 32-разрядную, так и 64-разрядную реализацию J2SE, содержащуюся в одной и той же установке Java, вы можете указать любую версию. Если ни -d32, ни -d64 не указаны, по умолчанию выполняется в 32-битной среде. - person Vineet Reynolds; 30.05.2011
comment
@vineet: да, вы говорите, что выходные данные java -version -d32 и java -version -d64 должны быть разными? У меня такое ощущение, что Java выполняла только часть java -version и игнорировала -d32 или -d64. Я попытался указать некоторые другие значения, например java -version -d100, но он также вернул тот же результат. - person jasonline; 30.05.2011
comment
@jasonline, да, я бы ожидал, что версии будут разными; только 64-битная версия JVM должна сообщать о 64-битном флаге. К сожалению, я помню поведение в Linux и Windows (где выходные данные разные), а не в Solaris, поэтому я не могу это подтвердить. Но поведение вашего приложения предполагает, что я могу быть правдой. Возможно, он пытается загрузить 32-битные библиотеки в 64-битный процесс, что является незаконным. - person Vineet Reynolds; 30.05.2011
comment
@vineet: ... попытка загрузить 32-битные библиотеки в 64-битный процесс - да, я думаю, что это то, что происходит. В Windows я получаю тот же результат, например: Java (TM) SE Runtime Environment (сборка 1.6.0_20-b02) Клиентская виртуальная машина Java HotSpot (TM) (сборка 16.3-b01, смешанный режим, совместное использование) - person jasonline; 30.05.2011
comment
@jasonline, да, это то, что я имел в виду, строка в Windows для 32-битных JVM не передает архитектуру, в то время как 64-битные версии передают. JVM Solaris может иметь другое поведение, учитывая способ, которым она установлена ​​для новых версий, и поэтому я не могу поручиться за такое же поведение. - person Vineet Reynolds; 30.05.2011
comment
@vineet: Странно. Моя Windows XP 32-битная. Почему мое приложение работает так, как будто это 64-разрядный процесс? Вы знаете, почему JVM не принимает параметр -d32 / d64? Он не отображается при отображении в / usr / ucb / ps - person jasonline; 30.05.2011
comment
@jasonline: как конкретно вы запускаете свое приложение? - person trutheality; 30.05.2011
comment
@jasonline, я не уверен, почему ps не сообщает о флагах. Однако есть еще один тест, чтобы проверить, является ли процесс 32-битным или 64-битным. Используйте pflags <pid>, где pid - это JVM. 32-битный процесс использует модель данных ILP32, в то время как 64-битный процесс использует модель LP64. Это более точно в вашем случае, так как он сообщает данные из базового процесса. Вам необходимо убедиться, что JVM не порождает новые процессы, использующие ProcessBuilder или связанные классы Java. - person Vineet Reynolds; 30.05.2011
comment
@trutheality: я использую сценарий: java ‹, за которым следуют параметры и т. д.›. - person jasonline; 30.05.2011
comment
@jasonline, вы продолжаете видеть LP64, когда передаете флаг -d32? Если да, то есть несколько возможностей - 1. есть ошибка в JVM. 2. сценарий не передает флаг -d32. 3. Установленная JVM является строго 64-битной версией и не будет работать в 32-битном режиме. - person Vineet Reynolds; 30.05.2011
comment
@vineet: Да, я вижу LP64, даже если передан флаг -d32. Думаю, я вижу возможную проблему. java указывает на файл sun4u64.sunos.5.8. Я думаю, мне нужно изменить это, чтобы указать на не 64-разрядную версию, чтобы она могла работать как 32-разрядное приложение. Не стесняйтесь размещать ответ, чтобы я мог его выбрать. - person jasonline; 30.05.2011
comment
@jasonline, я думаю, вам следует попытаться установить самую последнюю версию JVM и использовать ее для своего приложения. В идеале это должно гарантировать, что все три пункта покрыты, поскольку более новая версия будет (и, как известно) принять флаг -d32, а также работать в 32-битном режиме по умолчанию, предполагая, что ошибок нет. - person Vineet Reynolds; 30.05.2011
comment
@vineet: Спасибо за вашу помощь. - person jasonline; 30.05.2011