On 01/10/2014 20:43, KI7MT wrote:
> i Joe, Bill,
Hi Greg,
>
> 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.
I would leave that in, you only need the bin directory on PATH as that
is where the DLL gets installed. We don't currently use the DLL but it
is harmless and will become necessary when, eventually, we go to using
an official release of hamlib 3.
>
> 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.
Hopefully a good number of v1.4 users. ~60 already reporting to
PSKReporter at the last update.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
> 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
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
------------------------------------------------------------------------------
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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
