Experimental Physics and
Industrial Control System

"Johnson, Andrew N." <[email protected]> · Wed, 21 Oct 2015 03:17:39 +0000

Hi Michael,

I don't know for sure, but here are some guesses. If the library you're linking against is a .so you wouldn't want to be able to link against one that hasn't been installed, since the build directory won't always be present at runtime — it's legal to do 'make clean' after building which would delete the build directory (but not the install directory) or to point INSTALL_LOCATION to somewhere outside the source tree; the source does not have to be visible from the machine running the final executables.

My guess is that there needs to be another (possibly order-only) rule to ensure the library installation happens before the executable is linked. The omission would probably be mine, I made some changes to the rules that build the .dll and .dll.a files. I may need reminding to look at that when I get back from vacation.

- Andrew

-- 
Sent from my iPad

> On Oct 20, 2015, at 12:28 PM, Michael Davidsaver <[email protected]> wrote:
> 
> I've occasionally run into weirdness when I have a PROD linking against a LIBRARY built in the same directory.  Is there some reason that the build directory isn't included in the linker search path?  That is "-L." in addition to "-L$(TOP)/lib/$(T_A)".
> 
> In this case I discovered that the mingw cross compiler now includes libevr.a, as does mrfioc2...  At least in this case the order of the rules tries to link the executable before the locally built library is installed $(TOP)/lib, so the linker finds the system library.  I'd imagine that in other situations this could result in linking against an older version of a library.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System