Не удалось найти -lGL, как обойтись без символической ссылки? - PullRequest
1 голос
/ 15 декабря 2011

Я компилирую разделяемую библиотеку с -lGL в команде ld. Но он не может найти libGL.so в моей системе. Пакет Nvidia правильно установил путь к библиотекам в /etc/ld.so.conf.d/. Даже вывод ldconfig -p | grep libGL.so нашел его:

libGL.so.1 (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so.1
libGL.so.1 (libc6) => /usr/lib32/nvidia-current/libGL.so.1
libGL.so (libc6,x86-64, OS ABI: Linux 2.4.20) => /usr/lib/x86_64-linux-gnu/libGL.so
libGL.so (libc6,x86-64) => /usr/lib/nvidia-current/libGL.so
libGL.so (libc6, OS ABI: Linux 2.4.20) => /usr/lib32/libGL.so
libGL.so (libc6) => /usr/lib32/nvidia-current/libGL.so

Я почти везде читал, что для связи с ним у меня есть в основном 2 решения:

  1. Свяжите nvidia libGL.so со стандартным каталогом / usr / lib. Это кажется неправильным для всех, кто попытается скомпилировать библиотеку opengl. Почему компоновщик не использует кеш ldconfig?

  2. Добавить вручную -L / usr / lib / nvidia-current в путь поиска библиотеки. Опять же, неправильно, как я могу узнать каждый путь, где библиотека может быть найдена во всей системе?

Итак, мой настоящий вопрос: каков стандартный и автоматический подход для связи с библиотекой не в стандартном местоположении, но местоположение уже зарегистрировано с помощью /etc/ld.so.conf?

1 Ответ

1 голос
/ 15 декабря 2011

/etc/ld.so.conf используется /lib/ld.so для разрешения общих библиотек во время выполнения, это не имеет ничего общего со связыванием содержимого во время компиляции.

Что нужно сделать, так это просто установить ссылку на libGL.so в /usr/lib/x86_64-linux-gnu/, и приложение будет использовать nvidia libGL.so во время выполнения. Это не должно быть проблемой, потому что интерфейс OpenGL стабилен и символы одинаковы в обеих библиотеках, реализация отличается.

...