Menu
▾
▴
wsjt-devel
|
From: Joe T. <jo...@pr...> - 2014-10-01 17:41:51
|
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?
-- Joe
|
|
From: KI7MT <ki...@ya...> - 2014-10-01 18:03:16
|
Hi Joe, Setting to null would correct any inadvertent settings of the Path elsewhere I would think. The other question is, how is that getting in there to begin with if the env / build script is not, or should not, be picking up any of the local env variables. Can you add it to jtsdk-qtenv.bat, jtsdk-cmake.bat and jtsdk-wsjtxrc.bat then test it to see the results, as I would not be able to test it properly from my end? I remember when we were using G95, that was one thing it wanted was to set the Lib_PATH's, but I don't recall any such requirement for Qt5 Tool-Chains. I also used RapidEE from the ..\tools directory to ensure the system variables were clean. 73's Greg, KI7MT On 10/1/2014 17:41, Joe Taylor wrote: > 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? > > -- Joe > > ------------------------------------------------------------------------------ > 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 |
|
From: Bill S. <g4...@cl...> - 2014-10-01 18:06:46
|
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. |
|
From: KI7MT <ki...@ya...> - 2014-10-01 18:18:30
|
Hi Bill, 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 ? 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. > > 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 |
|
From: Bill S. <g4...@cl...> - 2014-10-01 18:35:13
|
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. |
|
From: KI7MT <ki...@ya...> - 2014-10-01 18:45:44
|
Hi Bill, On 10/1/2014 18:35, Bill Somerville wrote: <snip> >> 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. Yes, that's how I figured out what needed, so I copied them over. +1, I'm not a fan of Windows either :-). > > 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. OK, We can do that with a batch file easy enough. >> >>> 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 |
|
From: Bill S. <g4...@cl...> - 2014-10-01 19:43:34
|
On 01/10/2014 19:35, Bill Somerville wrote: > On 01/10/2014 19:18, KI7MT wrote: > >> 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. Further to this: on Windows Qt installs, the reason Qt has all the Qt DLLs (debug and release) in the Qt bin directory along with the tools like moc, uic, rcc, qmake, dumpcpp, ... is that is their solution to testing Qt applications before deployment. You simply have the Qt bin directory on PATH and it all works without copying anything or setting any other environment variables. I note that the JTSDK-QT adds the plugin directories to PATH as well. This has no effect because the plugins are located via hard coded paths in the Qt core DLL which are set up at install time (one of the reasons that moving the Qt install breaks it). This is necessary because the plugins are not loaded by the system loader, they are loaded explicitly by the Qt core library. Deployed applications have to be shipped with a qt.conf file which among other things is used to override the hard coded plugins path in the core library. We write a qt.conf file in Release configuration builds that refers to the plugin directory in the install destination. <snip> 73 Bill G4WJS. |
|
From: Bill S. <g4...@cl...> - 2014-10-01 19:49:06
|
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
>> wsj...@li...
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
|
|
From: KI7MT <ki...@ya...> - 2014-10-01 19:54:26
|
Hi Bill,
I have internet issues something chronic at the moment. T-Bird said this
email failed to deliver like 5 times, so if you get multiples of it,
apologies for that :-)
I got your other mail about plugins as well. The next update can take
them out if not needed.
On 10/1/2014 19:48, Bill Somerville wrote:
> 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.
OK, sounds good.
>>
>> 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.
Yes, been watching that also.
>>
>> 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
>>> wsj...@li...
>>> 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
> wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
--
73's
Greg, KI7MT
|
|
From: Laurie V. <vk3...@gm...> - 2014-10-02 00:31:21
|
As I type this, I can see that 83 JTAlert users are running v1.4. There have been no reported errors on the HamApps group. de Laurie, VK3AMA ------------------------------------------------------------------------ On 2/10/2014 5:48 AM, Bill Somerville wrote: > Hopefully a good number of v1.4 users. ~60 already reporting to > PSKReporter at the last update. >> > |
|
From: Joe T. <jo...@pr...> - 2014-10-01 18:47:20
|
RR, 4427 is OK. But if LIBRARY_PATH defined to be a NULL string, why include it in PATH at all? -- Joe On 10/1/2014 2:40 PM, KI7MT wrote: > Hi Joe, > > Yes, it did here too. Had to move the %LIBRARY_PATH% to the end of the > %PATH% > > Should be ok now, I just built WSPR and WSJT-X > > 73's > Greg, KI7MT > > > > > On 10/1/2014 18:34, Joe Taylor wrote: >> Greg -- >> >> SVN revisions 4425 and 4426 break everything here. >> >> I think all that's needed is >> >> SET LIBRARY_PATH="" >> >> in jtsdk-qtenv.bat, and possibly also in jtsdk-pyenv.bat. Don't put >> LIBRARY_PATH into PATH... they're two different things. You don't use >> LIBRARY_PATH anywhere in your scripts, but some of the tools do. We >> want it defined as NULL, even if a user normally has it set otherwise >> (for use in other environments). >> >> -- Joe > > ------------------------------------------------------------------------------ > 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 |
|
From: KI7MT <ki...@ya...> - 2014-10-01 18:57:04
|
Hi Joe, I took it off the %PATH% string for all 5 files, and was testing all the builds before sending the next update. 73's Greg, KI7MT On 10/1/2014 18:47, Joe Taylor wrote: > RR, 4427 is OK. > > But if LIBRARY_PATH defined to be a NULL string, why include it in PATH > at all? > > -- Joe > > On 10/1/2014 2:40 PM, KI7MT wrote: >> Hi Joe, >> >> Yes, it did here too. Had to move the %LIBRARY_PATH% to the end of the >> %PATH% >> >> Should be ok now, I just built WSPR and WSJT-X >> >> 73's >> Greg, KI7MT >> >> >> >> >> On 10/1/2014 18:34, Joe Taylor wrote: >>> Greg -- >>> >>> SVN revisions 4425 and 4426 break everything here. >>> >>> I think all that's needed is >>> >>> SET LIBRARY_PATH="" >>> >>> in jtsdk-qtenv.bat, and possibly also in jtsdk-pyenv.bat. Don't put >>> LIBRARY_PATH into PATH... they're two different things. You don't use >>> LIBRARY_PATH anywhere in your scripts, but some of the tools do. We >>> want it defined as NULL, even if a user normally has it set otherwise >>> (for use in other environments). >>> >>> -- Joe >> >> ------------------------------------------------------------------------------ >> 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 > > ------------------------------------------------------------------------------ > 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 |
|
From: KI7MT <ki...@ya...> - 2014-10-01 19:44:20
|
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
|
|
From: Joe T. <jo...@pr...> - 2014-10-01 18:35:08
|
Greg -- SVN revisions 4425 and 4426 break everything here. I think all that's needed is SET LIBRARY_PATH="" in jtsdk-qtenv.bat, and possibly also in jtsdk-pyenv.bat. Don't put LIBRARY_PATH into PATH... they're two different things. You don't use LIBRARY_PATH anywhere in your scripts, but some of the tools do. We want it defined as NULL, even if a user normally has it set otherwise (for use in other environments). -- Joe |
|
From: KI7MT <ki...@ya...> - 2014-10-01 18:40:38
|
Hi Joe, Yes, it did here too. Had to move the %LIBRARY_PATH% to the end of the %PATH% Should be ok now, I just built WSPR and WSJT-X 73's Greg, KI7MT On 10/1/2014 18:34, Joe Taylor wrote: > Greg -- > > SVN revisions 4425 and 4426 break everything here. > > I think all that's needed is > > SET LIBRARY_PATH="" > > in jtsdk-qtenv.bat, and possibly also in jtsdk-pyenv.bat. Don't put > LIBRARY_PATH into PATH... they're two different things. You don't use > LIBRARY_PATH anywhere in your scripts, but some of the tools do. We > want it defined as NULL, even if a user normally has it set otherwise > (for use in other environments). > > -- Joe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X