История изменений

Написал по этому вопросу в libtool mailing list. Последний вопрос-ответ там не сохранился (может как-то криво отправли), вот они:

Thank you for reply.

Since you mention /usr/local/lib, can you confirm that LDFLAGS includes -L/usr/local/lib or that this argument was otherwise supplied to libtool?

No, I did not use the -L flag. When passing to libtool -L /usr/local/lib, the executable is linked to libmy.la (it is ok).

I think that libtool attempts to deduce the compiler’s default linking path so that it does not duplicate the default. However, the compiler’s default linking path might not match what is used by the operating system.

By «know in advance», do you mean that as a software developer you can’t know the configuration of some other system while building, …

Yes, I use atotools+libtool. As a developer, how can I discover library paths of end user which will build my package? For example, he has installed libraries in $HOME/lib, has set appropriate LIBRARY_PATH and has edited /etc/ld.so.conf so that they point to $HOME/lib. But libtool will not know about this and will not find those libraries. I thought libtool should somehow synchronize path information with linkers.

What is the right way when linking? Assigning most probable paths (/lib, /usr/lib, /usr/local/lib) with -L? $ libtool–mode=link g++ -L/lib -L/usr/lib -L/usr/local/lib … And if end user violates standard layout then this is his problem.

This is indeed a problem and likely not one with a perfect solution. Libtool is just a script. It asks GCC what paths it will use while linking. Sometimes GCC does not tell the truth.

Linux (I am assuming you are using Linux since you did not say) may use a different path based on the ldconfig configuration, which may be changed by the system administrator.

An important consideration is that a library may be installed multiple times. For example, I may install an updated/fixed version of a library in /usr/local/lib and I want my updated/fixed version to be used rather than the version installed by the OS’s package manager. In this case I would prefer that the directory path be in the opposite order you suggested. In this case, I might also want to use ldconfig to change the library search order, or perhaps I might hard-code the library run-path so that this is not necessary.

The golden rule should be that if the user specifies LDFLAGS to the configure script, that the linker search path specified there should always be given priority over defaults. This allows the user to take remedial action if the built-in assumptions are not correct.

If the user is doing something out of the ordinary (developers often do that!), then s/he should be able to influence the build process so search the correct directories for libraries and install to the correct location. The standard environment variables and arguments for influencing the build are provided by the standard INSTALL file.

Bob
Bob Friesenhahn

=======================================================

Хз, для меня так и осталось тайной - почему libtool не синхронизирует пути поиска lib с ld …

Написал по этому вопросу в libtool mailing list. Последний вопрос-ответ там не сохранился (может как-то криво отправли), вот они:

Thank you for reply.

Since you mention /usr/local/lib, can you confirm that LDFLAGS includes -L/usr/local/lib or that this argument was otherwise supplied to libtool?

No, I did not use the -L flag. When passing to libtool -L /usr/local/lib, the executable is linked to libmy.la (it is ok).

I think that libtool attempts to deduce the compiler’s default linking path so that it does not duplicate the default. However, the compiler’s default linking path might not match what is used by the operating system.

By «know in advance», do you mean that as a software developer you can’t know the configuration of some other system while building, …

Yes, I use atotools+libtool. As a developer, how can I discover library paths of end user which will build my package? For example, he has installed libraries in $HOME/lib, has set appropriate LIBRARY_PATH and has edited /etc/ld.so.conf so that they point to $HOME/lib. But libtool will not know about this and will not find those libraries. I thought libtool should somehow synchronize path information with linkers.

What is the right way when linking? Assigning most probable paths (/lib, /usr/lib, /usr/local/lib) with -L? $ libtool–mode=link g++ -L/lib -L/usr/lib -L/usr/local/lib … And if end user violates standard layout then this is his problem.

This is indeed a problem and likely not one with a perfect solution. Libtool is just a script. It asks GCC what paths it will use while linking. Sometimes GCC does not tell the truth.

Linux (I am assuming you are using Linux since you did not say) may use a different path based on the ldconfig configuration, which may be changed by the system administrator.

An important consideration is that a library may be installed multiple times. For example, I may install an updated/fixed version of a library in /usr/local/lib and I want my updated/fixed version to be used rather than the version installed by the OS’s package manager. In this case I would prefer that the directory path be in the opposite order you suggested. In this case, I might also want to use ldconfig to change the library search order, or perhaps I might hard-code the library run-path so that this is not necessary.

The golden rule should be that if the user specifies LDFLAGS to the configure script, that the linker search path specified there should always be given priority over defaults. This allows the user to take remedial action if the built-in assumptions are not correct.

If the user is doing something out of the ordinary (developers often do that!), then s/he should be able to influence the build process so search the correct directories for libraries and install to the correct location. The standard environment variables and arguments for influencing the build are provided by the standard INSTALL file.

Bob

Bob Friesenhahn

Хз, для меня так и осталось тайной - почему libtool не синхронизирует пути поиска lib с ld …