Недавно я предпринял проект по созданию статической и динамической версий библиотеки, которую я использую, которая написана и поддерживается другим программистом здесь. В основном я делал это для упражнения, но дополнительные программы наверняка найдут путь к этой машине, поэтому я решил, почему бы не создать динамическую библиотеку и не сэкономить место на любых новых исполняемых файлах, которые наверняка будут использовать эту библиотеку. Итак, сегодня я установил новую программу на машину, и я написал сценарий оболочки для проверки отсутствующих библиотек, прежде чем поместить ее в работающую среду. В моей производственной / клиентской системе скрипт сгенерировал это сообщение:
/lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.17' not found (required by /usr/local/lib/libUtilityQQ.so)
И мои машины для разработки и производства работают на wheezy, и они оба Raspberry Pi 2s. Я не уверен, как я получил этот libc 2.17 от glibc. На выпуске pi есть libc 2.13, судя по ссылкам в / lib. Я обнаружил, что /etc/apt/sources.list был изменен в моем окне разработки (мной, без сомнения), и машины работают с разными ядрами, но это никогда не было проблемой раньше.
Основное развитие пи:
uname -a:
Linux qfuel-dev 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l GNU/Linux
/etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
deb http://http.debian.net/debian wheezy-backports main
Производство пи:
uname -a:
Linux pa0036 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux
/etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
Очевидно, что эти машины имеют разные ядра. Это может быть один метод, который открыт для меня, чтобы обновить glibc. (?)
Этот клиент находится в нескольких штатах, поэтому я не знаю, является ли обновление моего ядра мной удаленно хорошей идеей или вообще возможно.
Теперь, когда я думаю об этом, я недавно создал новую версию g ++, но я не использую ее, продолжая использовать 4.6.3. Я думаю, что новый libc был построен вместе с кодом компилятора?
Задача ещё не решена.
Других решений пока нет …