Local lib installation path not searched when library found in system location

[Ralph Lange]

When a module creates a library that is also installed in a system location, the first make run does not add the local library installation path to the linker lines for creating shared libraries and products.

When running make a second time, or if the library is not found in a system location, the local lib installation path is correctly added.

Reason: the EPICS build system is only adding *existing* library locations to the linker line.
When the first make starts, the local lib installation dir does not exist, and is not added to the search path since the (installed) library is found in the system location. A non-existing local lib install path is only added as a fallback if the library is not found in a system location.

Proposal:
Instead of adding a non-existing local lib installation dir only as a fallback (if the library is not found in a system location), the local lib installation dir should be added unconditionally, at the front of the search path.

Workaround:
Add
    SHRLIBDIR_LDFLAGS += -L$(INSTALL_LIB)
    PRODDIR_LDFLAGS += -L$(INSTALL_LIB)
e.g. in Base (or the application's) CONFIG_SITE.

[Ralph Lange (ralph-lange)]

That workaround is obviously a Linux-only solution...

The final fix should properly use the architecture/OS specific way of adding search paths.

[Ralph Lange (ralph-lange)]

A matching change will have to be added to the dependency tree.

Else a PROD will be built against the system location library before the local library is being generated.

[mdavidsaver (mdavidsaver)]

http://www.aps.anl.gov/epics/core-talk/2015/msg00553.php

[Andrew Johnson (anj)]

This patch adds $(INSTALL_DIR) to the list of library search directories on the link line if it isn't already there, and applies to all Unix architectures. Linking on Windows involves giving the full path to each library anyway, so there is no equivlent change required there. I believe this fixes the reported problem, but I haven't reproduced the original setup so I'd appreciate confirmation of that.

I believe the issue Michael referred to in his core-talk message is a different problem (which I think I've just found).

[Ralph Lange (ralph-lange)]

Yes, I can confirm that the path works. Thanks a lot, please apply.

What about the dependencies? Is it guaranteed that libraries are being built before PRODs that use them, even if there's an older version of the library in a system location?