0

In my configure/configure.ac, I do multiple PKG_CHECK_MODULES calls. Most of them return the same -I path:-I/usr/local/include, and also the same -L path: -L/usr/local/lib.

I would say that -I path doesn't do any difference, because gcc compiles one source at time. It might make a difference when multiple sources would be compiled?

However, it probably does make a difference for libraries, as following constructs are possible:

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

I guess that each -L option changes current top library search path.

Is this all correct? Should I ignore -I redundance, or try to collapse the paths? How to collapse them?

(PS. Please don't get confused about letters in -I, -l: the first one is capital "i", the include path option about which I am asking)

Sachin
  • 40,216
  • 7
  • 90
  • 102
Roffal
  • 3
  • 1

2 Answers2

0

Each -L option actually just adds something to the end of the current search path, which means that linking against different libraries in different locations is a hard problem to produce a general solution for. If you have the same two libraries in two locations A and B, and you want the first library from A and the second library from B, it's surprisingly annoying to do that with -L options. You end up having to include the full path to the .so file on the link line instead.

In other words, in:

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

libcups will be searched for in /usr/local/lib first, then /usr/lib, and then /opt/lib. If there is a libcups in /usr/local/lib, you'll still get the wrong one. About the only way to be sure is to replace -L/opt/lib -lcups with /opt/lib/libcups.so (which is not as portable; it doesn't work on HP-UX or AIX, for example).

To answer your question, for the most part people don't bother trying to clean up the redundancy. This sort of compilation command line is fairly typical in projects that use multiple libraries.

rra
  • 3,807
  • 18
  • 29
0

You can modify PKG_CHECK_MODULES to place the necessary flags into LDFLAGS and CPPFLAGS rather than FOO_LIBS and FOO_CFLAGS and have it check if the results of pkg-config are redundant, not adding them if already present. While doing so, it would be wise to add some invocations of AC_CHECK_LIB to validate the information returned by pkg-config. This has the added benefit of substantially cleaning up all of your Makefile.am, since they no longer need to explicitly reference @FOO_LIBS@ and @FOO_CFLAGS@. But, it's probably easier to just stop using PKG_CHECK_MODULES. (see PKG_CHECK_MODULES considered harmful?)

Community
  • 1
  • 1
William Pursell
  • 204,365
  • 48
  • 270
  • 300