Почему OS X 10.8 Mountain Lion не находит библиотеки X11 при создании программного обеспечения?

Итак, мы все знаем, что Mountain Lion больше не поставляется с X11, и пользователям, которым нужен X11, предлагается загрузить Xquartz. Xquartz устанавливается на /opt, но также создает символические ссылки X11 и X11R6 на /usr. Но при создании программного обеспечения, требующего ссылки на включаемые файлы X11, я обнаружил, что должен передать переменную среды, добавляя /usr/X11/include (или /opt/X11/include) к пути поиска библиотеки, чтобы получить ./configure для поиска библиотек X11. Мой вопрос: почему?

Я провел некоторое исследование в Google (многие результаты указывают на переполнение стека), и я прочитал документацию Apple, и все эти источники указывают, что в OS X нет эквивалента файлу /etc/ld.so.conf, найденному во многих (если не во всех ) дистрибутивов Linux. Apple даже заявляет, что DYLD_LIBRARY_PATH по умолчанию пусто. Однако под Lion (с установленным последним «официальным» X11 от Apple) те же самые сценарии ./configure будут находить библиотеки X11, не добавляя ничего в путь поиска библиотек.

Итак, почему скрипты ./configure не могут найти библиотеки X11 в Mountain Lion без явного изменения пути поиска библиотек?


x11 dyld osx-mountain-lion
person Chip Warden    schedule 28.07.2012    source источник
comment
Какой пример приложения X11 вы пытаетесь настроить... и результат настройки? Например, если я загружаю xpdf, он находит мои библиотеки X на Mountain Lion, а я не Не думаю, что я сделал что-то особенное (помимо установки XQuartz).   -  person Stennie    schedule 30.07.2012
comment
В частности, Руби 1.8.7. Вы можете увидеть проблему и решение здесь: stackoverflow.com/questions/11664835/ Как я уже сказал в исходном вопросе, я решил проблему. Мне просто интересно, знает ли кто-нибудь, почему это поведение отличается в Mountain Lion с Xquartz и Lion с Apple X11.   -  person Chip Warden    schedule 30.07.2012

Ответы (1)


arrow_upward
1
arrow_downward

Спрашивал больше года назад... но так как я пришел сюда с похожей проблемой...

Обратите внимание, что в упомянутом вопросе ruby ​​не был изменен путь поиска библиотеки. Это решение просто устанавливает переменную среды, которая используется многими файлами Makefile в качестве флагов для компилятора C++. В этом примере определено время сборки -I ncludepath, т. е. где искать .h eaders, а не библиотеки (что было бы - L к вашему компилятору/компоновщику). Оба были бы вариантами времени сборки. Независимо от того, LD_LIBRARY_PATH или DYLD_LIBRARY_PATH — обе переменные среды учитываются динамическим компоновщиком во время выполнения. (Подробнее см. http://en.wikipedia.org/wiki/Dynamic_linker).

У меня нет под рукой машины до 10.8, но думаю, что могла быть символическая ссылка /usr/include/X11 -> /opt/X11/include/X11 -- иначе я понятия не имею, как это могло работать раньше, если исходники те же...

Это еще одно потенциальное решение таких проблем (только что исправил мою сборку realvnc):

$ autoconf
$ ./configure

Итак, ваш вопрос «почему?» в конечном итоге можно было бы ответить следующим образом: потому что ваши исходные коды содержали «предварительно созданный» сценарий конфигурации, основанный на старых автоинструментах, которые не включали /opt/X11/include в качестве потенциального места для поиска включений X11 или просто не получали некоторые из них. вышеупомянутые флаги времени компиляции прямо в вашей текущей системе. У меня есть autoconf, установленный через homebrew — ааа, отличная штука, ура.

person user44958    schedule 18.10.2013