Re: [wsjt-devel] Hamlib3 compile error

2017-03-06 Thread Greg Beam
Hi Dan,

You should be able to install Msys, with autotools, to the default 
C:\MinGW or whatever it is these days. After which you'd need to copy a 
couple of files from the original /msys/etc folder (for mount points and 
such) and edit one file to update a path for the new installation of 
MSYS. Its not difficult. If you want to attempt this email me offline 
and I'll give you the step by step instructions.

73's
Greg, KI7MT


On 3/6/2017 8:57 AM, Dan Malcolm wrote:
> Bill,
> I actually do understand, and thank God for the Bill's and Greg's of this
> world.  My development efforts these days revolves around PHP and the PhpED
> editor.  A much more dragon free environment.  Of course it is programming
> and as such will never be completely dragon free.  Remember the old joke
> about devil and 10 lines of perfect code?
>
> Can we do this?  You tell me what JTSDK architecture you think I need, and
> given what I have in place, I will try to manipulate files/directories to
> match that.  The first problem to solve is getting the needed tools in
> place.  Perhaps then the procedures you provided will work.  That should
> relieve some of my demands on your time, as long as I can still ask the odd
> question.  At least now I have a sense of what needs to happen.  If it all
> fails,  I can just use the release version of WSJTX.
>
> Thanks Bill, and thanks to you to Greg.
>
> _
> Dan Malcolm CFI/II
> K4SHQ
>
>
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Monday, March 06, 2017 9:29 AM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Hamlib3 compile error
>
> On 06/03/2017 14:51, Dan Malcolm wrote:
>> What to do?  Since I have the MinGW Installation Manager I guess I
>> could install everything it offers, but it may be installed in the
>> wrong place to do any good.  Thinking of our email exchanges it seems
>> you expect a lot of utilities to be available and available in a
>> particular place.  Is it possible that something went missing during my
> initial package installation?
>
> Hi Dan,
>
> I need to clarify a few things.
>
> Firstly MinGW is Windows port of the GNU compilers. These are essential as
> we use them to build WSJT-X. You get a version of them as part of the Qt
> install and they match the compilers used to make the Qt libraries and
> tools. This in turn is essential so that projects like WSJT-X can use them
> and be compatible with the Qt libraries.
>
> We also use the Hamlib project for rig control. Unlike Qt which just needs
> MinGW compilers, Hamlib uses the fairly standard autotools as well that
> thousands of Open Source projects use. For autotools to work a Unix like
> shell environment is required and there is one available that goes with
> MinGW, it is called msys. Msys provides a command shell and many utilities
> that would be found on a Unix like system.
>
> The problem with DLL load addresses is a Microsoft issue in that they use a
> binary format that is not position independent. I have no idea why DLLs
> suddenly stop working with fork() emulations, it just happens sometimes. The
> cure is to rebase the relevant DLLs, rebasing in this context is looking at
> the size of each DLL and allocating a unique load address hint to each one
> so that none ever need to be loaded at a different address due to
> overlapping, at least until whatever causes this happens again. It is this
> loading into a process virtual address space at a different address that
> causes the fork() emulations to fail.
>
> It appears that the JTSDK does not provide enough of the msys environment to
> run this rarely required utility, that I tried to help you with but I am
> largely working blind as I do not use the JTSDK and do not wish to install
> it due constraints of other projects. Believe me that rebaseall is what you
> need, it is designed to resolve exactly this issue with one simple command
> invocation.
>
> It is quite possible to install each of the required tools and libraries
> that are needed to build WSJT-X individually. Greg has taken the time to
> build a relatively simple to use package that obviates the user from
> understanding and doing all this work. He provides the minimum needed to do
> the most basic build tasks which works well for almost everyone. In your
> case you have hit an issue that needs a deeper understanding and more
> components to resolve. I am afraid that using standard tools for software
> development is complex and usually messy, you are living in a charmed world
> where someone like Greg has smoothed down all the sharp edges for you but
> nearby there be dragons and one of them has walk

Re: [wsjt-devel] Hamlib3 compile error

2017-03-06 Thread Dan Malcolm
Bill,
I actually do understand, and thank God for the Bill's and Greg's of this
world.  My development efforts these days revolves around PHP and the PhpED
editor.  A much more dragon free environment.  Of course it is programming
and as such will never be completely dragon free.  Remember the old joke
about devil and 10 lines of perfect code?  

Can we do this?  You tell me what JTSDK architecture you think I need, and
given what I have in place, I will try to manipulate files/directories to
match that.  The first problem to solve is getting the needed tools in
place.  Perhaps then the procedures you provided will work.  That should
relieve some of my demands on your time, as long as I can still ask the odd
question.  At least now I have a sense of what needs to happen.  If it all
fails,  I can just use the release version of WSJTX.

Thanks Bill, and thanks to you to Greg.

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, March 06, 2017 9:29 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 06/03/2017 14:51, Dan Malcolm wrote:
> What to do?  Since I have the MinGW Installation Manager I guess I 
> could install everything it offers, but it may be installed in the 
> wrong place to do any good.  Thinking of our email exchanges it seems 
> you expect a lot of utilities to be available and available in a 
> particular place.  Is it possible that something went missing during my
initial package installation?

Hi Dan,

I need to clarify a few things.

Firstly MinGW is Windows port of the GNU compilers. These are essential as
we use them to build WSJT-X. You get a version of them as part of the Qt
install and they match the compilers used to make the Qt libraries and
tools. This in turn is essential so that projects like WSJT-X can use them
and be compatible with the Qt libraries.

We also use the Hamlib project for rig control. Unlike Qt which just needs
MinGW compilers, Hamlib uses the fairly standard autotools as well that
thousands of Open Source projects use. For autotools to work a Unix like
shell environment is required and there is one available that goes with
MinGW, it is called msys. Msys provides a command shell and many utilities
that would be found on a Unix like system.

The problem with DLL load addresses is a Microsoft issue in that they use a
binary format that is not position independent. I have no idea why DLLs
suddenly stop working with fork() emulations, it just happens sometimes. The
cure is to rebase the relevant DLLs, rebasing in this context is looking at
the size of each DLL and allocating a unique load address hint to each one
so that none ever need to be loaded at a different address due to
overlapping, at least until whatever causes this happens again. It is this
loading into a process virtual address space at a different address that
causes the fork() emulations to fail.

It appears that the JTSDK does not provide enough of the msys environment to
run this rarely required utility, that I tried to help you with but I am
largely working blind as I do not use the JTSDK and do not wish to install
it due constraints of other projects. Believe me that rebaseall is what you
need, it is designed to resolve exactly this issue with one simple command
invocation.

It is quite possible to install each of the required tools and libraries
that are needed to build WSJT-X individually. Greg has taken the time to
build a relatively simple to use package that obviates the user from
understanding and doing all this work. He provides the minimum needed to do
the most basic build tasks which works well for almost everyone. In your
case you have hit an issue that needs a deeper understanding and more
components to resolve. I am afraid that using standard tools for software
development is complex and usually messy, you are living in a charmed world
where someone like Greg has smoothed down all the sharp edges for you but
nearby there be dragons and one of them has walked out of the forest in your
direction.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-06 Thread Bill Somerville
On 06/03/2017 14:51, Dan Malcolm wrote:
> What to do?  Since I have the MinGW Installation Manager I guess I could
> install everything it offers, but it may be installed in the wrong place to
> do any good.  Thinking of our email exchanges it seems you expect a lot of
> utilities to be available and available in a particular place.  Is it
> possible that something went missing during my initial package installation?

Hi Dan,

I need to clarify a few things.

Firstly MinGW is Windows port of the GNU compilers. These are essential 
as we use them to build WSJT-X. You get a version of them as part of the 
Qt install and they match the compilers used to make the Qt libraries 
and tools. This in turn is essential so that projects like WSJT-X can 
use them and be compatible with the Qt libraries.

We also use the Hamlib project for rig control. Unlike Qt which just 
needs MinGW compilers, Hamlib uses the fairly standard autotools as well 
that thousands of Open Source projects use. For autotools to work a Unix 
like shell environment is required and there is one available that goes 
with MinGW, it is called msys. Msys provides a command shell and many 
utilities that would be found on a Unix like system.

The problem with DLL load addresses is a Microsoft issue in that they 
use a binary format that is not position independent. I have no idea why 
DLLs suddenly stop working with fork() emulations, it just happens 
sometimes. The cure is to rebase the relevant DLLs, rebasing in this 
context is looking at the size of each DLL and allocating a unique load 
address hint to each one so that none ever need to be loaded at a 
different address due to overlapping, at least until whatever causes 
this happens again. It is this loading into a process virtual address 
space at a different address that causes the fork() emulations to fail.

It appears that the JTSDK does not provide enough of the msys 
environment to run this rarely required utility, that I tried to help 
you with but I am largely working blind as I do not use the JTSDK and do 
not wish to install it due constraints of other projects. Believe me 
that rebaseall is what you need, it is designed to resolve exactly this 
issue with one simple command invocation.

It is quite possible to install each of the required tools and libraries 
that are needed to build WSJT-X individually. Greg has taken the time to 
build a relatively simple to use package that obviates the user from 
understanding and doing all this work. He provides the minimum needed to 
do the most basic build tasks which works well for almost everyone. In 
your case you have hit an issue that needs a deeper understanding and 
more components to resolve. I am afraid that using standard tools for 
software development is complex and usually messy, you are living in a 
charmed world where someone like Greg has smoothed down all the sharp 
edges for you but nearby there be dragons and one of them has walked out 
of the forest in your direction.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-06 Thread Black Michael
For a quick test just rename your mingw directory...you probably have C:\MINGW 
or such.
It may be conflicting.
de Mike W9MDB

  From: Dan Malcolm 
 To: 'WSJT software development'  
 Sent: Monday, March 6, 2017 8:51 AM
 Subject: Re: [wsjt-devel] Hamlib3 compile error
   
Bill,
This is getting ridiculous.  I really appreciate your patience and
expertise, but it seems that what is supposed to be there just isn't.  Now I
can run rebaseall from dash.exe but not as /bin/rebaseall, but as rebaseall.
In addition rebaseall errors out saying it can't find 'lib'.  I am also
having to substitute mingw32 for mingw because there is no mingw in JTSDK.

A long time ago I set up and maintained a Slackware Linux mail server, so I
am familiar with but by no means an expert with UNIX.  Still, I appreciate
the 'fork' explanation.  I didn't know there was a difference between UNIX
and Windows in how they share libraries.

What to do?  Since I have the MinGW Installation Manager I guess I could
install everything it offers, but it may be installed in the wrong place to
do any good.  Thinking of our email exchanges it seems you expect a lot of
utilities to be available and available in a particular place.  Is it
possible that something went missing during my initial package installation?
Several months ago when I first installed JTSDK, it all just
worked.until it all of sudden didn't.  Uninstalled and deleted the JTSDK
directory, and started over.  The problem didn't change.  You've seen my
list of installed packages.  Did I miss something?  Should I wipe it out and
start over?  Should I install all of MinGW?  Fortunately the one thing I do
have is plenty of HD space with a 1TB SSD and more than half empty.

I really appreciate your time and advice

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, March 06, 2017 5:54 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 06/03/2017 03:50, Dan Malcolm wrote:
> Got that and installed it.  MIngw-get still failed but a search found 
> the program under C:\JTSDK\mingw32\bin so I used the full path from 
> the JTSDK MYS prompt.  That ran and seemed to install a few pages.  
> Closed all JTSDK windows and then found dash.exe right where you said 
> it would be.  It opened a window and /bin/rebaseall gave me this error:
> $ /bin/rebaseall
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found

Hi Dan,

Hmmm, this may become a bit lengthy. Let me try and explain why rebaseall is
needed. Unix like systems use a system call named fork() to create all new
processes by exactly copying the memory content of the current process to
make a new child process, this is fundamental to how shells run programs.
Because msys is the MinGW (GNU gcc compilers on
Windows) shell and is based on Unix principles it needs an emulation of
fork() for Windows. Windows has a different way of creating processes with
the CreateProcess[Ex]() system call which does something very different. One
behaviour of Unix like systems is that in a forked child process any
references shared libraries (like DLLs) are loaded at exactly the same
virtual address in the new process as the old one. This is an
oversimplification as Unix like systems really use a technique called
position independent code but it amounts to the same thing. This means that
code pre-compiled to call shared library routines will continue to work in
the child process. In Windows this can go wrong as DLL code can appear at
different addresses in different processes. The rebase action fixes up the
msys and MinGW DLLs so that does not happen.

So what to do? I suspect that you can install enough of the msys system to
allow the rebseall command to work but it might take a few attempts. 
At least you have the mingw-get tool available now to install new packages.
Try this from a JTSDK msys prompt:

mingw-get install msys-base

and if it works try the procedure to run rebaseall from a dash shell again.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel m

Re: [wsjt-devel] Hamlib3 compile error

2017-03-06 Thread Dan Malcolm
Bill,
This is getting ridiculous.  I really appreciate your patience and
expertise, but it seems that what is supposed to be there just isn't.  Now I
can run rebaseall from dash.exe but not as /bin/rebaseall, but as rebaseall.
In addition rebaseall errors out saying it can't find 'lib'.  I am also
having to substitute mingw32 for mingw because there is no mingw in JTSDK.

A long time ago I set up and maintained a Slackware Linux mail server, so I
am familiar with but by no means an expert with UNIX.  Still, I appreciate
the 'fork' explanation.  I didn't know there was a difference between UNIX
and Windows in how they share libraries.

What to do?  Since I have the MinGW Installation Manager I guess I could
install everything it offers, but it may be installed in the wrong place to
do any good.  Thinking of our email exchanges it seems you expect a lot of
utilities to be available and available in a particular place.  Is it
possible that something went missing during my initial package installation?
Several months ago when I first installed JTSDK, it all just
worked.until it all of sudden didn't.  Uninstalled and deleted the JTSDK
directory, and started over.  The problem didn't change.  You've seen my
list of installed packages.  Did I miss something?  Should I wipe it out and
start over?  Should I install all of MinGW?  Fortunately the one thing I do
have is plenty of HD space with a 1TB SSD and more than half empty.

I really appreciate your time and advice

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Monday, March 06, 2017 5:54 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 06/03/2017 03:50, Dan Malcolm wrote:
> Got that and installed it.  MIngw-get still failed but a search found 
> the program under C:\JTSDK\mingw32\bin so I used the full path from 
> the JTSDK MYS prompt.  That ran and seemed to install a few pages.  
> Closed all JTSDK windows and then found dash.exe right where you said 
> it would be.  It opened a window and /bin/rebaseall gave me this error:
> $ /bin/rebaseall
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found

Hi Dan,

Hmmm, this may become a bit lengthy. Let me try and explain why rebaseall is
needed. Unix like systems use a system call named fork() to create all new
processes by exactly copying the memory content of the current process to
make a new child process, this is fundamental to how shells run programs.
Because msys is the MinGW (GNU gcc compilers on
Windows) shell and is based on Unix principles it needs an emulation of
fork() for Windows. Windows has a different way of creating processes with
the CreateProcess[Ex]() system call which does something very different. One
behaviour of Unix like systems is that in a forked child process any
references shared libraries (like DLLs) are loaded at exactly the same
virtual address in the new process as the old one. This is an
oversimplification as Unix like systems really use a technique called
position independent code but it amounts to the same thing. This means that
code pre-compiled to call shared library routines will continue to work in
the child process. In Windows this can go wrong as DLL code can appear at
different addresses in different processes. The rebase action fixes up the
msys and MinGW DLLs so that does not happen.

So what to do? I suspect that you can install enough of the msys system to
allow the rebseall command to work but it might take a few attempts. 
At least you have the mingw-get tool available now to install new packages.
Try this from a JTSDK msys prompt:

mingw-get install msys-base

and if it works try the procedure to run rebaseall from a dash shell again.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-06 Thread Bill Somerville
On 06/03/2017 03:50, Dan Malcolm wrote:
> Got that and installed it.  MIngw-get still failed but a search found the
> program under C:\JTSDK\mingw32\bin so I used the full path from the JTSDK
> MYS prompt.  That ran and seemed to install a few pages.  Closed all JTSDK
> windows and then found dash.exe right where you said it would be.  It opened
> a window and /bin/rebaseall gave me this error:
> $ /bin/rebaseall
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found

Hi Dan,

Hmmm, this may become a bit lengthy. Let me try and explain why 
rebaseall is needed. Unix like systems use a system call named fork() to 
create all new processes by exactly copying the memory content of the 
current process to make a new child process, this is fundamental to how 
shells run programs. Because msys is the MinGW (GNU gcc compilers on 
Windows) shell and is based on Unix principles it needs an emulation of 
fork() for Windows. Windows has a different way of creating processes 
with the CreateProcess[Ex]() system call which does something very 
different. One behaviour of Unix like systems is that in a forked child 
process any references shared libraries (like DLLs) are loaded at 
exactly the same virtual address in the new process as the old one. This 
is an oversimplification as Unix like systems really use a technique 
called position independent code but it amounts to the same thing. This 
means that code pre-compiled to call shared library routines will 
continue to work in the child process. In Windows this can go wrong as 
DLL code can appear at different addresses in different processes. The 
rebase action fixes up the msys and MinGW DLLs so that does not happen.

So what to do? I suspect that you can install enough of the msys system 
to allow the rebseall command to work but it might take a few attempts. 
At least you have the mingw-get tool available now to install new 
packages. Try this from a JTSDK msys prompt:

mingw-get install msys-base

and if it works try the procedure to run rebaseall from a dash shell again.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Greg Beam
Hi Dan,

I can't speak to the rebase situation, however, one has to keep in mind 
the purpose of the MSYS environment as part of JTSDK. It is not a full 
MSYS image/environment instalaltion, it's the chain image, meaning, it's 
there to support for the use of GCC, C++, gfortran, and autotools, not 
an interactive user environment. The MSYS work-space is not even 
installed (though there are a few msys dll's to support the tool chain 
binary requirements), as it is not needed (normally) for the tool chain 
to perform it's intended function. mingw-get is not part of the tool 
chain side, it's part of the MSYS environment / installer side.

This is evident by the fact, grep and find are in the C:/JTSDK/msys/bin 
directory. However, the default or "assumed" profile for mingw-get is 
looking for those binaries in a non-existent MSYS /bin directory (which 
it cannot find), not the tool-chain /bin directory.

I'm not certain, but I believe mingwe-get needs a profile file to tell 
it where MSYS is located along with the tool chain folder ../mingw or 
../mingw32 / wherever the tool chain is located.


73's
Greg, KI7MT

On 3/5/2017 8:50 PM, Dan Malcolm wrote:
> Bill,
> Got that and installed it.  MIngw-get still failed but a search found the
> program under C:\JTSDK\mingw32\bin so I used the full path from the JTSDK
> MYS prompt.  That ran and seemed to install a few pages.  Closed all JTSDK
> windows and then found dash.exe right where you said it would be.  It opened
> a window and /bin/rebaseall gave me this error:
> $ /bin/rebaseall
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> /bin/rebaseall: 207: find: not found
> /bin/rebaseall: 207: grep: not found
> _
> Dan Malcolm CFI/II
> K4SHQ
>
>
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Sunday, March 05, 2017 8:53 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Hamlib3 compile error
>
> On 06/03/2017 02:43, Dan Malcolm wrote:
>> The very first step failed with 'bash.exe: mingw-get: command not found'.
>
> HI Dan,
>
> Ah, that's not helpful.
>
> Try this:
>
> https://sourceforge.net/projects/mingw/files/
>
> you want the mingw-get-setup.exe installer offered at the top of the page.
>
> 73
> Bill
> G4WJS.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Dan Malcolm
Bill,
Got that and installed it.  MIngw-get still failed but a search found the
program under C:\JTSDK\mingw32\bin so I used the full path from the JTSDK
MYS prompt.  That ran and seemed to install a few pages.  Closed all JTSDK
windows and then found dash.exe right where you said it would be.  It opened
a window and /bin/rebaseall gave me this error:
$ /bin/rebaseall
/bin/rebaseall: 207: find: not found
/bin/rebaseall: 207: grep: not found
/bin/rebaseall: 207: find: not found
/bin/rebaseall: 207: grep: not found
_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, March 05, 2017 8:53 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 06/03/2017 02:43, Dan Malcolm wrote:
> The very first step failed with 'bash.exe: mingw-get: command not found'.

HI Dan,

Ah, that's not helpful.

Try this:

https://sourceforge.net/projects/mingw/files/

you want the mingw-get-setup.exe installer offered at the top of the page.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Bill Somerville
On 06/03/2017 02:43, Dan Malcolm wrote:
> The very first step failed with 'bash.exe: mingw-get: command not found'.

HI Dan,

Ah, that's not helpful.

Try this:

https://sourceforge.net/projects/mingw/files/

you want the mingw-get-setup.exe installer offered at the top of the page.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Dan Malcolm
The very first step failed with 'bash.exe: mingw-get: command not found'. 
_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, March 05, 2017 6:00 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 05/03/2017 23:31, Dan Malcolm wrote:
> The build log is attached.

Hi Dan,

try the following:-

Open a JTSDK MSYS prompt and type:

mingw-get install msys-rebase

Exit the MSYS window and any other MSYS window that might be open -- this
step is important.

In Windows open a File Explorer window (Windows-Key+E) and navigate to the
MSYS bin folder. It will be something like:

C:\JTSDK\MinGW\msys\1.0\bin

Scroll down until you locate dash.exe and double click it. A small command
window should open. Type the following:

/bin/rebaseall

then hit ENTER. It should take a minute or so to complete.

Quit the dash window by tying CTRL+D.

Now try the build again.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Bill Somerville
On 05/03/2017 23:31, Dan Malcolm wrote:
> The build log is attached.

Hi Dan,

try the following:-

Open a JTSDK MSYS prompt and type:

mingw-get install msys-rebase

Exit the MSYS window and any other MSYS window that might be open -- 
this step is important.

In Windows open a File Explorer window (Windows-Key+E) and navigate to 
the MSYS bin folder. It will be something like:

C:\JTSDK\MinGW\msys\1.0\bin

Scroll down until you locate dash.exe and double click it. A small 
command window should open. Type the following:

/bin/rebaseall

then hit ENTER. It should take a minute or so to complete.

Quit the dash window by tying CTRL+D.

Now try the build again.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Dan Malcolm
Bill,
Sorry but I used your earlier example as I thought that would also capture
stderr.  Attached is the 'tee' version.  I don't see any difference.  The
'&' in the command line caused an error so it wasn't used.

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Sunday, March 05, 2017 4:20 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 06/03/2017 01:37, Greg Beam wrote:
> build-hamlib3 |tee -a hamlib3-build.log
>
> That should scroll the build on the screen and create a build log for you.

Hi Dan & all,

better to use:

build-hamlib3 |& tee hamlib3-build.log

so that any error output sent to the stderr stream is also sent to the log
file and a fresh log file is created for each run.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


hamlib3-build-tee.log
Description: Binary data
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Dan Malcolm
Bill,
The build log is attached.

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Dan Malcolm [mailto:dmalcol...@mchsi.com] 
Sent: Saturday, March 04, 2017 7:36 PM
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Hamlib3 compile error

Ok Bill,
That's no problem if someone can tell me how exactly.  I found the Autoconf
file but the text says not to directly edit it, so I didn't.  I also didn't
find any place to edit the make command line.  

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Saturday, March 04, 2017 1:57 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 04/03/2017 19:21, Dan Malcolm wrote:
> v5.8.8 built for msys-64int

Hi Dan,

ok, that also is fine. I need to see the full and verbose Hamlib build
output. Problem is I'm not sure how to do that with the JTSDK, maybe Greg is
lurking and can help out. What is needed is to add V=1 to the Hamlib make
command and also to redirect all the output (stderr and
stdout) to a log file. Then zip and send me that file please?

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Build-Hamlib3.log
Description: Binary data
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Bill Somerville
On 06/03/2017 01:37, Greg Beam wrote:
> build-hamlib3 |tee -a hamlib3-build.log
>
> That should scroll the build on the screen and create a build log for you.

Hi Dan & all,

better to use:

build-hamlib3 |& tee hamlib3-build.log

so that any error output sent to the stderr stream is also sent to the 
log file and a fresh log file is created for each run.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Greg Beam
Hi Dan,

The shell script for building Hamlib can be found at:

C:\JTSDK\sctipts\msys-build-hamlib3.sh

On or about line 254 is the make command, just add the V=1 after it:

make V=1

if that is what Bill needs.

Because it's a script doing the work, just tee the output to a file from 
within MSYS (there is an alias to call the script):

build-hamlib3 |tee -a hamlib3-build.log

That should scroll the build on the screen and create a build log for you.

73's
Greg, KI7MT


On 3/4/2017 12:57 PM, Bill Somerville wrote:
> On 04/03/2017 19:21, Dan Malcolm wrote:
>> v5.8.8 built for msys-64int
>
> Hi Dan,
>
> ok, that also is fine. I need to see the full and verbose Hamlib build
> output. Problem is I'm not sure how to do that with the JTSDK, maybe
> Greg is lurking and can help out. What is needed is to add V=1 to the
> Hamlib make command and also to redirect all the output (stderr and
> stdout) to a log file. Then zip and send me that file please?
>
> 73
> Bill
> G4WJS.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Dan Malcolm
Greg,
Bill thinks adding V=1 to the make command line may show something.  Neither
of us know how to do that in JTSDK.  Can you help with that?

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Sunday, March 05, 2017 10:46 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

Hi Dan,

I was mistaken on the msys-64int. I checked my version of Perl via different
method that only yields the version number. Using --version on my
installation also returns 64int in the name. I also checked the dll headers
with dumpbin and it's definitely a 32 bit dll, so you can take that rabbit
trail off the table, sorry about that.

I've tried several methods to reproduce the error your seeing, but, have had
no luck thus far. At present, I am at a loss as to what is causing your
error.

73's
Greg, KI7MT



> On 03/04/2017 06:35 PM, Dan Malcolm wrote:
>> Ok Bill,
>> That's no problem if someone can tell me how exactly.  I found the 
>> Autoconf file but the text says not to directly edit it, so I didn't.  
>> I also didn't find any place to edit the make command line.
>>
>> _
>> Dan Malcolm CFI/II
>> K4SHQ
>>
>>
>> -Original Message-
>> From: Bill Somerville [mailto:g4...@classdesign.com]
>> Sent: Saturday, March 04, 2017 1:57 PM
>> To: wsjt-devel@lists.sourceforge.net
>> Subject: Re: [wsjt-devel] Hamlib3 compile error
>>
>> On 04/03/2017 19:21, Dan Malcolm wrote:
>>> v5.8.8 built for msys-64int
>>
>> Hi Dan,
>>
>> ok, that also is fine. I need to see the full and verbose Hamlib 
>> build output. Problem is I'm not sure how to do that with the JTSDK, 
>> maybe Greg is lurking and can help out. What is needed is to add V=1 
>> to the Hamlib make command and also to redirect all the output 
>> (stderr and
>> stdout) to a log file. Then zip and send me that file please?
>>
>> 73
>> Bill
>> G4WJS.
>>


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Dan Malcolm
Actually I was surprised to see it was 64 bit also, but since there is a lot
I don't know about JTSDK, I thought that was normal.  At least until I read
your email I did.  This info is on a fresh install.  When this problem
started and rebooting didn't solve it, I uninstalled JTSDK, downloaded all
new packages from Sourceforge, and then reinstalled.  The packages I
downloaded are:
JTSDK-2.0.0-u1-win32.exe
JTSDK-2.0.0-u2-win32.exe
JTSDK-2.0.0-u3-win32.exe
JTSDK-2.0.0-u4-win32.exe
JTSDK-2.0.0-win32.exe

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: KI7MT [mailto:ki7m...@gmail.com] 
Sent: Sunday, March 05, 2017 12:15 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

Hi Dan, Bill,

I'm not sure how Dan got a 64-bit version of MSYS Perl installed, as the
installer I created had 32bit MSYS. All of the software in JTSDK is 32bit,
as are the WSJT packages it creates, unless something has changed.

Dan, Are you sure that Perl is 64bit and not 32bit?

73's
Greg, KI7MT

On 03/04/2017 06:35 PM, Dan Malcolm wrote:
> Ok Bill,
> That's no problem if someone can tell me how exactly.  I found the 
> Autoconf file but the text says not to directly edit it, so I didn't.  
> I also didn't find any place to edit the make command line.
> 
> _
> Dan Malcolm CFI/II
> K4SHQ
> 
> 
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Saturday, March 04, 2017 1:57 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Hamlib3 compile error
> 
> On 04/03/2017 19:21, Dan Malcolm wrote:
>> v5.8.8 built for msys-64int
> 
> Hi Dan,
> 
> ok, that also is fine. I need to see the full and verbose Hamlib build 
> output. Problem is I'm not sure how to do that with the JTSDK, maybe 
> Greg is lurking and can help out. What is needed is to add V=1 to the 
> Hamlib make command and also to redirect all the output (stderr and
> stdout) to a log file. Then zip and send me that file please?
> 
> 73
> Bill
> G4WJS.
> 


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-05 Thread Greg Beam
Hi Dan,

I was mistaken on the msys-64int. I checked my version of Perl via 
different method that only yields the version number. Using --version on 
my installation also returns 64int in the name. I also checked the dll 
headers with dumpbin and it's definitely a 32 bit dll, so you can take 
that rabbit trail off the table, sorry about that.

I've tried several methods to reproduce the error your seeing, but, have 
had no luck thus far. At present, I am at a loss as to what is causing 
your error.

73's
Greg, KI7MT



> On 03/04/2017 06:35 PM, Dan Malcolm wrote:
>> Ok Bill,
>> That's no problem if someone can tell me how exactly.  I found the Autoconf
>> file but the text says not to directly edit it, so I didn't.  I also didn't
>> find any place to edit the make command line.
>>
>> _
>> Dan Malcolm CFI/II
>> K4SHQ
>>
>>
>> -Original Message-
>> From: Bill Somerville [mailto:g4...@classdesign.com]
>> Sent: Saturday, March 04, 2017 1:57 PM
>> To: wsjt-devel@lists.sourceforge.net
>> Subject: Re: [wsjt-devel] Hamlib3 compile error
>>
>> On 04/03/2017 19:21, Dan Malcolm wrote:
>>> v5.8.8 built for msys-64int
>>
>> Hi Dan,
>>
>> ok, that also is fine. I need to see the full and verbose Hamlib build
>> output. Problem is I'm not sure how to do that with the JTSDK, maybe Greg is
>> lurking and can help out. What is needed is to add V=1 to the Hamlib make
>> command and also to redirect all the output (stderr and
>> stdout) to a log file. Then zip and send me that file please?
>>
>> 73
>> Bill
>> G4WJS.
>>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-04 Thread KI7MT
Hi Dan, Bill,

I'm not sure how Dan got a 64-bit version of MSYS Perl installed, as the
installer I created had 32bit MSYS. All of the software in JTSDK is
32bit, as are the WSJT packages it creates, unless something has changed.

Dan, Are you sure that Perl is 64bit and not 32bit?

73's
Greg, KI7MT

On 03/04/2017 06:35 PM, Dan Malcolm wrote:
> Ok Bill, 
> That's no problem if someone can tell me how exactly.  I found the Autoconf
> file but the text says not to directly edit it, so I didn't.  I also didn't
> find any place to edit the make command line.  
> 
> _
> Dan Malcolm CFI/II
> K4SHQ
> 
> 
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com] 
> Sent: Saturday, March 04, 2017 1:57 PM
> To: wsjt-devel@lists.sourceforge.net
> Subject: Re: [wsjt-devel] Hamlib3 compile error
> 
> On 04/03/2017 19:21, Dan Malcolm wrote:
>> v5.8.8 built for msys-64int
> 
> Hi Dan,
> 
> ok, that also is fine. I need to see the full and verbose Hamlib build
> output. Problem is I'm not sure how to do that with the JTSDK, maybe Greg is
> lurking and can help out. What is needed is to add V=1 to the Hamlib make
> command and also to redirect all the output (stderr and
> stdout) to a log file. Then zip and send me that file please?
> 
> 73
> Bill
> G4WJS.
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-04 Thread Dan Malcolm
Ok Bill, 
That's no problem if someone can tell me how exactly.  I found the Autoconf
file but the text says not to directly edit it, so I didn't.  I also didn't
find any place to edit the make command line.  

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Saturday, March 04, 2017 1:57 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 04/03/2017 19:21, Dan Malcolm wrote:
> v5.8.8 built for msys-64int

Hi Dan,

ok, that also is fine. I need to see the full and verbose Hamlib build
output. Problem is I'm not sure how to do that with the JTSDK, maybe Greg is
lurking and can help out. What is needed is to add V=1 to the Hamlib make
command and also to redirect all the output (stderr and
stdout) to a log file. Then zip and send me that file please?

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-04 Thread Bill Somerville
On 04/03/2017 19:21, Dan Malcolm wrote:
> v5.8.8 built for msys-64int

Hi Dan,

ok, that also is fine. I need to see the full and verbose Hamlib build 
output. Problem is I'm not sure how to do that with the JTSDK, maybe 
Greg is lurking and can help out. What is needed is to add V=1 to the 
Hamlib make command and also to redirect all the output (stderr and 
stdout) to a log file. Then zip and send me that file please?

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-04 Thread Dan Malcolm
v5.8.8 built for msys-64int

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Saturday, March 04, 2017 6:28 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 04/03/2017 03:38, Dan Malcolm wrote:
> >From JTSDK-MSYS prompt 'which perl' yields '/bin/perl.exe'

Hi Dan,

Ok, that seems fine. Next try:

perl --version

from the same command shell.

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-04 Thread Bill Somerville
On 04/03/2017 03:38, Dan Malcolm wrote:
> >From JTSDK-MSYS prompt 'which perl' yields '/bin/perl.exe'

Hi Dan,

Ok, that seems fine. Next try:

perl --version

from the same command shell.

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Dan Malcolm
>From JTSDK-MSYS prompt 'which perl' yields '/bin/perl.exe'

_
Dan Malcolm CFI/II
K4SHQ


-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Friday, March 03, 2017 9:22 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

On 04/03/2017 02:51, Dan Malcolm wrote:
> The very first error encountered is "Win32 error 998" which is 
> translated as "Invalid access to memory location".  Reading the Win10 
> Application log I find the faulting application is perl.exe and 
> faulting module is msys-perl5_8.dll subsequent errors fault the same file
or state 'unknown'.
> So far I have lots of indicator messages, but I don't yet have a 
> handle on the problem.

Hi Dan,

open a JTSDK command prompt and type:

which perl

and report back what is printed please?

73
Bill
G4WJS.



--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Bill Somerville
On 04/03/2017 02:51, Dan Malcolm wrote:
> The very first error encountered is "Win32 error 998" which is translated as
> "Invalid access to memory location".  Reading the Win10 Application log I
> find the faulting application is perl.exe and faulting module is
> msys-perl5_8.dll subsequent errors fault the same file or state 'unknown'.
> So far I have lots of indicator messages, but I don't yet have a handle on
> the problem.

Hi Dan,

open a JTSDK command prompt and type:

which perl

and report back what is printed please?

73
Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Dan Malcolm
All,
The very first error encountered is "Win32 error 998" which is translated as
"Invalid access to memory location".  Reading the Win10 Application log I
find the faulting application is perl.exe and faulting module is
msys-perl5_8.dll subsequent errors fault the same file or state 'unknown'.
So far I have lots of indicator messages, but I don't yet have a handle on
the problem.

Prior to yesterday I have been able to compile the devel package just fine,
and did so every week or so.  Obviously something changed on my computer.

_
Dan Malcolm CFI/II
K4SHQ

-Original Message-
From: Greg Beam [mailto:ki7m...@gmail.com] 
Sent: Friday, March 03, 2017 5:44 PM
To: WSJT software development 
Subject: Re: [wsjt-devel] Hamlib3 compile error

Hi Dan, All,

I'm not sure what's going on here either. My version of Perl, via MSYS, is
5.8.8. I was able to build Hamlib3 from MSYS directly, and JTSDK-QT via QT
5.2 and 5.5 without error.

As Bill suggested, log the build and post it. To eliminate JTSDK-QT ENV, use
the JTSDK-MSYS terminal, then:

 From JTSDK-MSYS Terminal, type the command:

build-hamlib3 |tee -a hamlib3-build.log

or

build-hamlib3 >> hamlib3-build.log

The first command allows you to watch the build progress. Then post that
file to the dev list.

As best I can tell, there are no versions of Perl associated with QT, so
that should not be a conflict of any sort. The update process within JTSDK
does not alter the MSYS installation. So, if the build worked at some point
in the past, something has changed in one of the environments on your
system. What, and where would be a question only you could answer.

73's
Greg, KI7MT

On 3/3/2017 10:58 AM, Dan Malcolm wrote:
> Bill,
>
> Reboot didn't help and the Windows Event Log messages just reported 
> what was already known.  I uninstalled JTSDK and then deleted the 
> folder.  I downloaded fresh files from SourceForge, and did a complete
reinstall.
> The problem is not fixed.  See the attached capture image.  WSJT-X 
> compilation also failed under JTSDK-QT.  There were so many error 
> lines that I could not scroll back far enough to see the first one.
> Experience has taught me to fix the first reported failure first.  Are 
> these problems related?
>
>
>
> _
>
> Dan Malcolm CFI/II
>
> K4SHQ
>
>
>
> *From:*Bill Somerville [mailto:g4...@classdesign.com]
> *Sent:* Thursday, March 02, 2017 10:21 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Hamlib3 compile error
>
>
>
> On 02/03/2017 16:06, Dan Malcolm wrote:
>
> Seems the offending module is: Faulting module path:
> C:\JTSDK\msys\bin\msys-perl5_8.dll.
>
> The problem seems to be inability to find a file
>
> It appears I am using Perl5_8.  If memory serves, there was a
> discussion about which Perl version should be used.  Could 5.8 be
> the problem?
>
> HI Dan,
>
> the message is telling us that the version of perl being used is the 
> one in the JTSDK. That should be fine. The errors were memory access 
> and copy errors. It could possibly be a corrupted file in the JTSDK. 
> If rebooting does not sort this out and there is nothing in the 
> Windows Event Log then it may be worth trying to re-install the JTSDK.
>
> 73
> Bill
> G4WJS.


--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Greg Beam
Hi Dan, All,

I'm not sure what's going on here either. My version of Perl, via MSYS, 
is 5.8.8. I was able to build Hamlib3 from MSYS directly, and JTSDK-QT 
via QT 5.2 and 5.5 without error.

As Bill suggested, log the build and post it. To eliminate JTSDK-QT ENV, 
use the JTSDK-MSYS terminal, then:

 From JTSDK-MSYS Terminal, type the command:

build-hamlib3 |tee -a hamlib3-build.log

or

build-hamlib3 >> hamlib3-build.log

The first command allows you to watch the build progress. Then post that 
file to the dev list.

As best I can tell, there are no versions of Perl associated with QT, so 
that should not be a conflict of any sort. The update process within 
JTSDK does not alter the MSYS installation. So, if the build worked at 
some point in the past, something has changed in one of the environments 
on your system. What, and where would be a question only you could answer.

73's
Greg, KI7MT

On 3/3/2017 10:58 AM, Dan Malcolm wrote:
> Bill,
>
> Reboot didn’t help and the Windows Event Log messages just reported what
> was already known.  I uninstalled JTSDK and then deleted the folder.  I
> downloaded fresh files from SourceForge, and did a complete reinstall.
> The problem is not fixed.  See the attached capture image.  WSJT-X
> compilation also failed under JTSDK-QT.  There were so many error lines
> that I could not scroll back far enough to see the first one.
> Experience has taught me to fix the first reported failure first.  Are
> these problems related?
>
>
>
> _
>
> Dan Malcolm CFI/II
>
> K4SHQ
>
>
>
> *From:*Bill Somerville [mailto:g4...@classdesign.com]
> *Sent:* Thursday, March 02, 2017 10:21 AM
> *To:* wsjt-devel@lists.sourceforge.net
> *Subject:* Re: [wsjt-devel] Hamlib3 compile error
>
>
>
> On 02/03/2017 16:06, Dan Malcolm wrote:
>
> Seems the offending module is: Faulting module path:
> C:\JTSDK\msys\bin\msys-perl5_8.dll.
>
> The problem seems to be inability to find a file
>
> It appears I am using Perl5_8.  If memory serves, there was a
> discussion about which Perl version should be used.  Could 5.8 be
> the problem?
>
> HI Dan,
>
> the message is telling us that the version of perl being used is the one
> in the JTSDK. That should be fine. The errors were memory access and
> copy errors. It could possibly be a corrupted file in the JTSDK. If
> rebooting does not sort this out and there is nothing in the Windows
> Event Log then it may be worth trying to re-install the JTSDK.
>
> 73
> Bill
> G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Bill Somerville

On 03/03/2017 18:47, Dan Malcolm wrote:
I still have the question: Are these two failures (Hamlib3 and WSJTX) 
related?


Hi Dan,

I don't know. Your instinct to examine the first error message is 
correct, I explained how you can do that.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Dan Malcolm
I know its my specific to my system.  Just not sure what it is.  There were
no install errors.  I still have the question: Are these two failures
(Hamlib3 and WSJTX) related?  I think not, but you know the architecture
better than I do. 



Dan Malcolm CFI/II

K4SHQ

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Friday, March 03, 2017 12:07 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

 

On 03/03/2017 17:58, Dan Malcolm wrote:

There were so many error lines that I could not scroll back far enough to
see the first one.  Experience has taught me to fix the first reported
failure first.  Are these problems related?

Hi Dan,

this is something specific to your system, no one else is reporting similar
issues.

To see the first error you need to redirect the build output to a file. Try:

build-command >build.log 2>&1

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-03 Thread Bill Somerville

On 03/03/2017 17:58, Dan Malcolm wrote:
There were so many error lines that I could not scroll back far enough 
to see the first one.  Experience has taught me to fix the first 
reported failure first.  Are these problems related?


Hi Dan,

this is something specific to your system, no one else is reporting 
similar issues.


To see the first error you need to redirect the build output to a file. Try:

build-command >build.log 2>&1

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-02 Thread Bill Somerville

On 02/03/2017 16:06, Dan Malcolm wrote:


Seems the offending module is: Faulting module path: 
C:\JTSDK\msys\bin\msys-perl5_8.dll.


The problem seems to be inability to find a file

It appears I am using Perl5_8.  If memory serves, there was a 
discussion about which Perl version should be used.  Could 5.8 be the 
problem?



HI Dan,

the message is telling us that the version of perl being used is the one 
in the JTSDK. That should be fine. The errors were memory access and 
copy errors. It could possibly be a corrupted file in the JTSDK. If 
rebooting does not sort this out and there is nothing in the Windows 
Event Log then it may be worth trying to re-install the JTSDK.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-02 Thread Dan Malcolm
Bill,

Seems the offending module is: Faulting module path:
C:\JTSDK\msys\bin\msys-perl5_8.dll.

The problem seems to be inability to find a file

It appears I am using Perl5_8.  If memory serves, there was a discussion
about which Perl version should be used.  Could 5.8 be the problem? 

 

_

Dan Malcolm CFI/II

K4SHQ

 

From: Bill Somerville [mailto:g4...@classdesign.com] 
Sent: Thursday, March 02, 2017 9:19 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] Hamlib3 compile error

 

On 02/03/2017 14:55, Dan Malcolm wrote:

Just tried to recompile Hamlib3 using JTSDK-MSYS and this is the result:

 

CDPATH="${ZSH_VERSION+.}:" && cd ../src && /bin/sh
/c/JTSDK/src/hamlib3/src/build-aux/missing --run aclocal-1.12 -I macros
--install

  0 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 16636, Win32 error 998

5046825 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 180, Win32 error 998

10094010 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 15560, Win32 error 998

15133523 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 24576, windows pid 18032, Win32 error 299

20176456 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 13908, Win32 error 998

25223284 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 19892, Win32 error 998

30279016 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 24576, windows pid 10168, Win32 error 299

  0 [main] perl 19868 open_stackdumpfile: Dumping stack trace to
perl.exe.stackdump

aclocal-1.12: error: autom4te terminated by signal: 11

Makefile:455: recipe for target `../src/aclocal.m4' failed

make: *** [../src/aclocal.m4] Error 1

Hi Dan,

those errors look nasty. Maybe some issue with memory management. First
thing to try is a reboot. If that doesn't sort it out then you need to look
at the Windows Event Log for recent items in the "Critical" or "Error"
category.

73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


Re: [wsjt-devel] Hamlib3 compile error

2017-03-02 Thread Bill Somerville

On 02/03/2017 14:55, Dan Malcolm wrote:


Just tried to recompile Hamlib3 using JTSDK-MSYS and this is the result:

CDPATH="${ZSH_VERSION+.}:" && cd ../src && /bin/sh 
/c/JTSDK/src/hamlib3/src/build-aux/missing --run aclocal-1.12 -I 
macros --install


  0 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 0, windows pid 16636, Win32 error 998


5046825 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 0, windows pid 180, Win32 error 998


10094010 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 0, windows pid 15560, Win32 error 998


15133523 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 24576, windows pid 18032, Win32 error 299


20176456 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 0, windows pid 13908, Win32 error 998


25223284 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 0, windows pid 19892, Win32 error 998


30279016 [main] perl 18760 fork_copy: linked dll data/bss pass 0 
failed, 0xF1E000..0xF3E794, done 24576, windows pid 10168, Win32 error 299


  0 [main] perl 19868 open_stackdumpfile: Dumping stack trace to 
perl.exe.stackdump


aclocal-1.12: error: autom4te terminated by signal: 11

Makefile:455: recipe for target `../src/aclocal.m4' failed

make: *** [../src/aclocal.m4] Error 1


Hi Dan,

those errors look nasty. Maybe some issue with memory management. First 
thing to try is a reboot. If that doesn't sort it out then you need to 
look at the Windows Event Log for recent items in the "Critical" or 
"Error" category.


73
Bill
G4WJS.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel


[wsjt-devel] Hamlib3 compile error

2017-03-02 Thread Dan Malcolm
Just tried to recompile Hamlib3 using JTSDK-MSYS and this is the result:

 

CDPATH="${ZSH_VERSION+.}:" && cd ../src && /bin/sh
/c/JTSDK/src/hamlib3/src/build-aux/missing --run aclocal-1.12 -I macros
--install

  0 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 16636, Win32 error 998

5046825 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 180, Win32 error 998

10094010 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 15560, Win32 error 998

15133523 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 24576, windows pid 18032, Win32 error 299

20176456 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 13908, Win32 error 998

25223284 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 0, windows pid 19892, Win32 error 998

30279016 [main] perl 18760 fork_copy: linked dll data/bss pass 0 failed,
0xF1E000..0xF3E794, done 24576, windows pid 10168, Win32 error 299

  0 [main] perl 19868 open_stackdumpfile: Dumping stack trace to
perl.exe.stackdump

aclocal-1.12: error: autom4te terminated by signal: 11

Makefile:455: recipe for target `../src/aclocal.m4' failed

make: *** [../src/aclocal.m4] Error 1

 

 

___

Dan Malcolm

K4SHQ


Politicians are people who, when they see light at the end
of the tunnel, go out and buy some more tunnel.

 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel