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

[KI7MT <ki...@ya...>]

i Joe, Bill,

I've updated the jtsdk-cmake.bat file so it *does not copy* files over
to install\Debug\bin, rather, it sets paths to GCC, FFTW, QT5 and Hamlib
Dir's.

I wasn't sure if we needed hamlib3\minge32\{bin,lib} or not so I added
them nonetheless. If not, we can take that back out.

It's running fine here. If you have any problems let me know, and I will
get it sorted out.

Bare in mind, the jtsdk-wsjtxrc.bat does not build Debug targets, only
release. If that is needed, I'll have to up update that script a fare
bit to accommodate the builds.

By the way, 10m JT65 is pretty hot at the moment.

73's
Greg, KI7MT

On 10/1/2014 18:35, Bill Somerville wrote:
> On 01/10/2014 19:18, KI7MT wrote:
>> Hi Bill,
> Hi Greg,
>>
>> On 10/1/2014 18:06, Bill Somerville wrote:
>>> 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.
>> So for the Debug builds, are you saying we don't need to copy the
>> runtime .dll's over too the install\bin directory ?
> Yes, that's the way it works for me.
> 
> Yuck! I hate Windows. I've just checked using the dependency walker and 
> it is indeed using PATH to locate the Qt debug DLLs at run time.
> 
> I have my Qt bin directory in my PATH when I debug or run debug builds 
> of WSJT-X. I think that is preferable to copying around the rather large 
> debug DLLs and plugins. Having said that, you must have the same on your 
> PATH at build time to get the Qt tools used by the build like moc, rcc, 
> uic, dumpcpp and, qmake. I use the same PATH settings for building, 
> running and, debugging.
> 
> My initial statement is correct for Linux and Mac but on Windows it 
> appears some help for the image loader is required.
>>
>> I've been copying gcc & Qt5 runtime libs over because Qt5 is not in my
>> env %PATH% var (by design) otherwise I get Missing Lib errors when running.
> OK, I think you need to have the Qt bin directory in your path when you 
> run Debug configured binaries. That's the way qt-project.org intend it 
> to be.
>>
>>> 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.
> 
> 
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> wsjt-devel mailing list
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 

-- 
73's
Greg, KI7MT