Замечание по ведению журнала

[vitus_wagner]

Если еще кто-то когда-то в моем журнале будет упоминать в положительном контексте что-либо, сделанное в рамках GNOME и KDE, буду банить как за мат.

Comments

[vitus_wagner]

А как узнать, что прописывать в PKG_CONFIG_PATH - lib/pkgconfig или lib64/pkgconfig? Так и тут узнать.
Все равно еще -m64 компилятору скармливать.

[dottedmag.livejournal.com]

Знает это собирающий тул (который, к примеру у dpkg узнаёт), а так ты эту ответственность складываешь на сам pkg-config, которому вообще пофиг, куда смотреть и на какой машине быть запущенным.

[vitus_wagner]

Неувязочка получается. Синтаксис ключика -L у компилятора pkgconfig знает, а какой там ELFCLASS - не должен знать.

Хотя на мой взгляд логичнее было бы наоборот - чтобы pkgconfig выдал бы
имена файлов с которыми линковаться (с указанием класса), а собирающий тул бы разбирался, как это правильно передать своему компилятору.

Тогда работа с библиотеками, которые собраны в рамках текущего проекта (и являются честными целями в Makefile) и работа с библиотеками из предустановленных пакетов, велась бы единообразно.

[dottedmag.livejournal.com]

Да ничего он не знает! Что в .pc написано - то и выдаст.

[vitus_wagner]

Ну тут собственно вопроса два:
1. Что в .pc писать
2. Где этот .pc искать.
Если уж pkg-config вынуждены были научить опции --msvc-syntax (и почему-то сделали её работающей только в Windows. Хотя что мне мешает генерировать под более другой системой командные файлы для сборки или вообще запускать cl.exe посредством wine?) то могли бы встроить в него немножко тайного знания на тему о том, какие бывают битности и где можно искать pc-файл для соответствующей битности.

Кстати, интеллекта на то, что для библиотеки, лежащей в нестандартном месте выдать не только -L, но и -R (или -Wl,-R или -Wl,-rpath) ему тоже не хватает.

В общем в текущем варианте выдачу этого самого pkg-config приходится все равно читать глазами и переписывать в Makefile руками.