Должны ли (и как это сделать) включать пути в свернутый скрипт?

Question

В моем configure/configure.acЯ делаю несколько PKG_CHECK_MODULES звонки. Большинство из них возвращают то же самое -I path:-I/usr/local/includeи тоже самое -L path: -L/usr/local/lib.

Я бы сказал, что -I path не имеет никакого значения, потому что gcc компилирует один источник за раз. Это может иметь значение, когда будет скомпилировано несколько источников?

Однако, это, вероятно, имеет значение для библиотек, так как возможны следующие конструкции:

-L / usr / local / lib -lX11 -L / usr / lib -lcurses -L / opt / lib -lcups

Я думаю, что каждый -L option изменяет текущий верхний путь поиска библиотеки.

Это все правильно? Должен ли я игнорировать -I Избыточность или попытаться свернуть пути? Как их свернуть?

(PS. Пожалуйста, не смущайтесь о письмах в -I, -l: первая столица "i"Опция пути включения, о которой я спрашиваю)

Answer 1

Каждый -L опция фактически просто добавляет что-то в конец текущего пути поиска, что означает, что связывание с разными библиотеками в разных местах является сложной проблемой, для которой необходимо найти общее решение. Если у вас две одинаковые библиотеки в двух местах A и B, и вы хотите первую библиотеку от A и вторую библиотеку от B, это удивительно раздражает -L опции. Вы заканчиваете тем, что включили полный путь к .so файл в строке ссылки вместо.

Другими словами, в:

-L/usr/local/lib -lX11 -L/usr/lib -lcurses -L/opt/lib -lcups

libcups будет искать в /usr/local/lib будет первый /usr/lib, а потом /opt/lib, Если есть libcups в /usr/local/lib, вы все равно получите неправильный. О единственном способе быть уверенным является замена -L/opt/lib -lcups с /opt/lib/libcups.so (который не так переносим; он не работает, например, в HP-UX или AIX).

Чтобы ответить на ваш вопрос, по большей части люди не удосуживаются пытаться устранить избыточность. Этот тип командной строки компиляции довольно типичен для проектов, использующих несколько библиотек.

Answer 2

Вы можете изменить PKG_CHECK_MODULES разместить необходимые флаги в LDFLAGS а также CPPFLAGS скорее, чем FOO_LIBS а также FOO_CFLAGS и проверить, если результаты pkg-config избыточны, не добавляя их, если они уже есть. При этом было бы целесообразно добавить несколько вызовов AC_CHECK_LIB проверить информацию, возвращенную pkg-config, Это имеет дополнительное преимущество в значительной степени очистить все ваши Makefile.am, поскольку им больше не нужно явно ссылаться @FOO_LIBS@ а также @FOO_CFLAGS@, Но, вероятно, проще просто перестать использовать PKG_CHECK_MODULES, (см. PKG_CHECK_MODULES считается вредным?)