Здравствуйте!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
Полная версия этой страницы: С*dence GLIBC_2.0
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Разработка цифровых, аналоговых, аналого-цифровых ИС
Цитата(-=Vitaly=- @ Aug 13 2007, 12:01) 
Здравствуйте!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
1.
Попробуй не ставить "железно" (на всё) эту переменную в стартовом файле, а сделай alias из
двух комманд - "определение LD_ASSUME_KERNEL";запуск coft-a
и запускай alias.
Если запуск софт-а script, то подправь его (или посмотри что там стоит по поводу LD_ASSUME_KERNEL)
Это иногда помогает.
Можно ещё посмотреть
ldd "софт.exe"
Ещё можно определить переменную
LD_DEBUG - LIBS или ALL (можно ещё попробовать сначала help)
запускать и смотреть что цепляется...
2.
А откуда взял "инфу"?
3. Специалисты по ldconfig откликнитесь !!!
Цитата(soshnev @ Aug 13 2007, 11:53)
1.
Попробуй не ставить "железно" (на всё) эту переменную в стартовом файле, а сделай alias из
двух комманд - "определение LD_ASSUME_KERNEL";запуск coft-a
и запускай alias.
Если запуск софт-а script, то подправь его (или посмотри что там стоит по поводу LD_ASSUME_KERNEL)
Это иногда помогает.
Можно ещё посмотреть
ldd "софт.exe"
Ещё можно определить переменную
LD_DEBUG - LIBS или ALL (можно ещё попробовать сначала help)
запускать и смотреть что цепляется...
2.
А откуда взял "инфу"?
3. Специалисты по ldconfig откликнитесь !!!
Попробуй не ставить "железно" (на всё) эту переменную в стартовом файле, а сделай alias из
двух комманд - "определение LD_ASSUME_KERNEL";запуск coft-a
и запускай alias.
Если запуск софт-а script, то подправь его (или посмотри что там стоит по поводу LD_ASSUME_KERNEL)
Это иногда помогает.
Можно ещё посмотреть
ldd "софт.exe"
Ещё можно определить переменную
LD_DEBUG - LIBS или ALL (можно ещё попробовать сначала help)
запускать и смотреть что цепляется...
2.
А откуда взял "инфу"?
3. Специалисты по ldconfig откликнитесь !!!
1. Попробую
2. http://electronix.ru/forum/index.php?showt...=14273&st=0
Цитата
(3.14 @ Mar 29 2006, 12:44) *
2) EDK не хочет запускаться sad.gif Утверждает:
_xps: error while loading shared libraries: libPortability.so: cannot open shared object file: No such file or directory
Это просто решить: Путь к бинарникам должен быть прописан в переменной окружения PATH.
Путь к библиотекам - в /etc/ld.so.conf. После его правки запусти от рута 'ldconfig'.
2) EDK не хочет запускаться sad.gif Утверждает:
_xps: error while loading shared libraries: libPortability.so: cannot open shared object file: No such file or directory
Это просто решить: Путь к бинарникам должен быть прописан в переменной окружения PATH.
Путь к библиотекам - в /etc/ld.so.conf. После его правки запусти от рута 'ldconfig'.
Очень похожий баг!
3. Специалисты по ldconfig откликнитесь !!!
4. Вопрос почему при опции LD_ASSUME_CONFIG=2.4.1 не запускается даже mc? Эта опция описана в пдф при установке Каденса для избавления траблов с GLIBC_2.0.
Цитата(-=Vitaly=- @ Aug 13 2007, 13:36)
1. Попробую
2. http://electronix.ru/forum/index.php?showt...=14273&st=0
Очень похожий баг!
3. Специалисты по ldconfig откликнитесь !!!
4. Вопрос почему при опции LD_ASSUME_CONFIG=2.4.1 не запускается даже mc? Эта опция описана в пдф при установке Каденса для избавления траблов с GLIBC_2.0.
2. http://electronix.ru/forum/index.php?showt...=14273&st=0
Очень похожий баг!
3. Специалисты по ldconfig откликнитесь !!!
4. Вопрос почему при опции LD_ASSUME_CONFIG=2.4.1 не запускается даже mc? Эта опция описана в пдф при установке Каденса для избавления траблов с GLIBC_2.0.
"Это просто решить: Путь к бинарникам должен быть прописан в переменной окружения PATH...."
1.
Есть ещё переменная LD_LIBRARY_PATH
должна содержать "софт__*.so__directory" и $LD_LIBRARY_PATH
2. mc не запускается поскольку уже выкручен LD_ASSUME_CONFIG (не тот).
Цитата(soshnev @ Aug 13 2007, 12:55)
"Это просто решить: Путь к бинарникам должен быть прописан в переменной окружения PATH...."
1.
Есть ещё переменная LD_LIBRARY_PATH
должна содержать "софт__*.so__directory" и $LD_LIBRARY_PATH
2. mc не запускается поскольку уже выкручен LD_ASSUME_CONFIG (не тот).
1.
Есть ещё переменная LD_LIBRARY_PATH
должна содержать "софт__*.so__directory" и $LD_LIBRARY_PATH
2. mc не запускается поскольку уже выкручен LD_ASSUME_CONFIG (не тот).
ОК, попробую, блин ошибся жестко там не LD_ASSUME_CONFIG a LD_ASSUME_KERNEL
Путь к бинарникам должен быть прописан в переменной окружения PATH...
Пардон за глупый вопрос к бинарникам линуха? Типа /bin: /usr/bin?
Цитата(-=Vitaly=- @ Aug 13 2007, 14:08)
ОК, попробую, блин ошибся жестко там не LD_ASSUME_CONFIG a LD_ASSUME_KERNEL
Путь к бинарникам должен быть прописан в переменной окружения PATH...
Пардон за глупый вопрос к бинарникам линуха? Типа /bin: /usr/bin?
Путь к бинарникам должен быть прописан в переменной окружения PATH...
Пардон за глупый вопрос к бинарникам линуха? Типа /bin: /usr/bin?
как я понял, имеется ввиду бинарники cadencе
по поводу С*dence GLIBC_2.0
под диструбутивом С*dence 6.14 помогает строчка
export LD_ASSUME_KERNEL=(а тут нужно прописать версию твоего ядра, а не 2.4.1 и без скобок)
or
setenv LD_ASSUME_KERNEL (----/---/----)
решения этого трабла мало где описаны, да и часто какие-то запутанные.
проще поставить "правильный" дистрибутив линукса или С*dence.
Цитата(-=Vitaly=- @ Aug 13 2007, 11:01)
Здравствуйте!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
Да, также есть возможность установки другой версии. на новые дистрибутивы хорошо становится IC_5.1.41_USR2
у меня стоит на SUSE10.2_64bit
Была аналогичная проблема
На 2007-ю Мандриву ну никак не хотел вставать IC5141 и LDV5.1
Проблема решилась установкой IC5141_USR2 (никакой LD_ASSUME_KERNEL прописывать не пришлось),
но LDV5.1 толком так и не заработал (simvision не запускался).
Долго копал инет, но решения проблемы так и не нашел.
Конечно Мандривы и Суси лучше встают на свежее железо, но используют более свежий GLIBC
а Кеданс собирает свои бинарники под более старый GLIBC (Linux Red-Hat Enterprise)
хотя более свежие версии переводит на более свежий GLIBC и проблема иногда решается.
В общем мое мнение.
Надо ставить тот линух который рекомендуют разработчики, а чаще всего это и у кеданса и у синопсиса
ред хат энтерпрайз или в последнее время еще и суся (ну или хотя бы линух с требуемым GLIBC)
, а проблемы с железом решать путем сборки более свежего ядра где нужное железо поддерживается
(это не очень сложно www.kernel.org).
На 2007-ю Мандриву ну никак не хотел вставать IC5141 и LDV5.1
Проблема решилась установкой IC5141_USR2 (никакой LD_ASSUME_KERNEL прописывать не пришлось),
но LDV5.1 толком так и не заработал (simvision не запускался).
Долго копал инет, но решения проблемы так и не нашел.
Конечно Мандривы и Суси лучше встают на свежее железо, но используют более свежий GLIBC
а Кеданс собирает свои бинарники под более старый GLIBC (Linux Red-Hat Enterprise)
хотя более свежие версии переводит на более свежий GLIBC и проблема иногда решается.
В общем мое мнение.
Надо ставить тот линух который рекомендуют разработчики, а чаще всего это и у кеданса и у синопсиса
ред хат энтерпрайз или в последнее время еще и суся (ну или хотя бы линух с требуемым GLIBC)
, а проблемы с железом решать путем сборки более свежего ядра где нужное железо поддерживается
(это не очень сложно www.kernel.org).
Цитата(-=Vitaly=- @ Aug 13 2007, 11:01)
Здравствуйте!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
Такая трабла - поставил софт под линукс Мандрива 2007, но он не запускается, говорит что
version GLIBC_2.0 not defined in file libc.so.6 with link time reference.
В пдф написано поставить переменную среды LD_ASSUME_KERNEL 2.4.1., но как только я ее ставлю перестают запускаться все программы с сообщением: error while loading shared libraries libc.so.6: cannot open shared file. Файлы в репорте разные,но эти файлы спокойно себе лежат в директории /lib.
Как это поправить?
Вроде нашел инфу, что это можно вылечить прописав в ld.so.conf пути
/lib
/lib/i686
, где лежат эти либы
Затем выполнить ldconfig, но чего-то не помогло, все равно пишет, что не может найти эти файлы.
Спасибо!
Для работы Cadence IC 5141 необходима версия GLIBC < 2.3. Идеально устанавливается на RED HAT 4 ( а так же его свободные версии Scientific Linux и CentOs). Слышал об успешных установках на Fedora 5 (почти тот же Red Hat) и SUSE 10.2. Сам долго пытался установить на мандриву, но в конце концов пришлось плюнуть.
Цитата(OsipovD @ Nov 6 2008, 19:32)
Для работы Cadence IC 5141 необходима версия GLIBC < 2.3. Идеально устанавливается на RED HAT 4 ( а так же его свободные версии Scientific Linux и CentOs). Слышал об успешных установках на Fedora 5 (почти тот же Red Hat) и SUSE 10.2. Сам долго пытался установить на мандриву, но в конце концов пришлось плюнуть.
ставил на мандриву 5141USR5. работает, но наблюдаются некоторые глюки.
LD_ASSUME_KERNEL помогало для старых ядер (на которых запускали совершенно старый софт)
потом это убрали, то есть объявляй/необъявляй разницы нет
в дебиане, когда возникала такая проблема - помогала установка старых либов - так называемых compat-xxx package
наверняка такое есть и в redhat/mandriva а вообще для пользования пакетом рекомендуется ставить древнючий линукс, для которого этот пакет тестирован самим производителем (это как правило RedHat 3.0)
потом это убрали, то есть объявляй/необъявляй разницы нет
в дебиане, когда возникала такая проблема - помогала установка старых либов - так называемых compat-xxx package
наверняка такое есть и в redhat/mandriva а вообще для пользования пакетом рекомендуется ставить древнючий линукс, для которого этот пакет тестирован самим производителем (это как правило RedHat 3.0)
Методом перебора нашел "ALT Linux 2.4 Master". Работаю под VMWare, поэтому "старое" ядро 2.4 совершенно не напрягает, зато оно очень нравится Кэденсу, оконный манагер IceWM кушает очень мало памяти.
Цитата(OsipovD @ Nov 6 2008, 18:32)
Для работы Cadence IC 5141 необходима версия GLIBC < 2.3. Идеально устанавливается на RED HAT 4 ( а так же его свободные версии Scientific Linux и CentOs). Слышал об успешных установках на Fedora 5 (почти тот же Red Hat) и SUSE 10.2. Сам долго пытался установить на мандриву, но в конце концов пришлось плюнуть.
Небольшая поправка: в Red Hat 4 glibc >= 2.3. Но на Debian Etch не завелось, хотя в нем версии библиотек практически те же:
RED HAT 4: glibc-2.3.4-2
Debian Etch: libc6-2.3.6.ds1-13etch7
Причина может крыться в параметрах сборки данных библиотек. Вот что выводит objdump -x /lib/libc.so.6 :
Red Hat 4:
CODE
---
Version definitions:
1 0x01 0x0865f4e6 libc.so.6
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
GLIBC_2.0
4 0x00 0x09691f71 GLIBC_2.1.1
GLIBC_2.1
5 0x00 0x09691f72 GLIBC_2.1.2
GLIBC_2.1.1
6 0x00 0x09691f73 GLIBC_2.1.3
GLIBC_2.1.2
7 0x00 0x0d696912 GLIBC_2.2
GLIBC_2.1.3
8 0x00 0x09691a71 GLIBC_2.2.1
GLIBC_2.2
9 0x00 0x09691a72 GLIBC_2.2.2
GLIBC_2.2.1
10 0x00 0x09691a73 GLIBC_2.2.3
GLIBC_2.2.2
11 0x00 0x09691a74 GLIBC_2.2.4
GLIBC_2.2.3
12 0x00 0x09691a76 GLIBC_2.2.6
GLIBC_2.2.4
13 0x00 0x0d696913 GLIBC_2.3
GLIBC_2.2.6
14 0x00 0x09691972 GLIBC_2.3.2
GLIBC_2.3
15 0x00 0x09691973 GLIBC_2.3.3
GLIBC_2.3.2
16 0x00 0x09691974 GLIBC_2.3.4
GLIBC_2.3.3
17 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.3.4
18 0x00 0x0b792650 GCC_3.0
Version References:
required from ld-linux.so.2:
0x0d696911 0x00 22 GLIBC_2.1
0x0d696913 0x00 21 GLIBC_2.3
0x0963cf85 0x00 20 GLIBC_PRIVATE
0x0d696910 0x00 19 GLIBC_2.0
---
Debian Etch:
CODE
---
Version definitions:
1 0x01 0x0865f4e6 libc.so.6
2 0x00 0x09691a75 GLIBC_2.2.5
3 0x00 0x09691a76 GLIBC_2.2.6
GLIBC_2.2.5
4 0x00 0x0d696913 GLIBC_2.3
GLIBC_2.2.6
5 0x00 0x09691972 GLIBC_2.3.2
GLIBC_2.3
6 0x00 0x09691973 GLIBC_2.3.3
GLIBC_2.3.2
7 0x00 0x09691974 GLIBC_2.3.4
GLIBC_2.3.3
8 0x00 0x0963cf85 GLIBC_PRIVATE
GLIBC_2.3.4
Version References:
required from ld-linux-x86-64.so.2:
0x09691a75 0x00 11 GLIBC_2.2.5
0x0d696913 0x00 10 GLIBC_2.3
0x0963cf85 0x00 09 GLIBC_PRIVATE
---
Отсюда видно, что в libc в Red Hat 4 определён интерфейс вплоть до версии 2.0, а в Debian - до 2.2.5. Насколько я понял из документации, наличие нескольких версий интерфейса в libc необходимо, чтобы при обновлении версии данной библиотеки система оставалась работоспособной (не отваливались приложения, слинкованные с более старой версией). При сборке libc по умолчанию присутствует интерфейс собираемой версии и текущей версии данной библиотеки. Может кто-нибудь подскажет, каким образом можно пересобрать libc, чтобы был определёны и более ранние версии.
Нужно будет попробовать поставить на Fedora Core 1.
А как IC5141 пойдет на RedHat 5.1 Server Enterprise?
А как IC5141 пойдет на RedHat 5.1 Server Enterprise?
Цитата(kleruoi @ Feb 4 2009, 18:11)
Нужно будет попробовать поставить на Fedora Core 1.
А как IC5141 пойдет на RedHat 5.1 Server Enterprise?
А как IC5141 пойдет на RedHat 5.1 Server Enterprise?
Прекрасно идет.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.