Re: [wsjt-devel] LIBRARY_PATH in JTSDK-QT

[Bill S. <g4...@cl...>]

On 01/10/2014 18:41, Joe Taylor wrote:

Hi Joe,
> Greg --
>
> I finally spent the necessary time to find out why builds of WSJT-X on
> one of my shack computers stopped working, a couple of weeks ago.
>
> Turns out that the machine in question has environment variable
> LIBRARY_PATH set as follows, at login:
>
> LIBRARY_PATH=c:\mingw\lib;c:\mingw\lib\gcc-lib\i686-pc-mingw32\4.0.3
>
> Obviously this is not good for builds in the JTSDKs!
>
> I suggest you put the following somewhere in jtsdk-qtenv.bat:
>
>      SET LIBRARY_PATH=""
>
> Does this make sense?
It does to me.

As an aside it is worth point out the library location strategy the the 
WSJT-X CMake build uses.

For Debug configuration builds all shared libraries (including Qt 
plugins) are located automatically from the location they were found at 
during linking. This means that Debug installs are small and sparse but 
are not portable. This is true on all platforms. So no setting of 
LIBRARY_PATH/LD_LIBRARY_PATH/DYLD_LIBRARY_PATH or similar environment 
variables should ever be needed. There is no need to copy any shared 
libraries into a WSJT-X debug install directory, the application will 
find the libraries just fine on its own. If you find that you need to 
copy in shared libraries or plugins then your Qt installation is 
probably broken, the easiest way to break a Qt installation is to move it.

For Release configuration builds all shared libraries and Qt plugins are 
either installed by the install phase or on Linux located from the 
system directories in their "normal" place. Any fix ups needed to make 
the resulting package portable are done by the build process. So no 
setting of LIBRARY_PATH/LD_LIBRARY_PATH/DYLD_LIBRARY_PATH or similar 
environment variables should ever be needed. This applies to RPATH 
embedded in Linux executabes and shared libraries too.

All of the above applies on all platforms.
>
> 	-- Joe
73
Bill
G4WJS.