Trouble with running cygwin dll on Vortex86MX+ CPU

Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

Hi Team,

I'm new here, but have dabbled in Cygwin for a few years. I hope someone 
more knowledgeable than myself can help with with this issue which is 
quite frankly baffling me for the past few weeks.

The problem I have can be reduced to this: I compile a simple "Hello 
World" console mode c program. I copy the .exe file and cygwin1.dll onto 
an embedded PC, open a console window, and run the program. The program 
runs, and returns immediately to the command prompt, with no output. No 
error messages, no nothing...

I can do the same on any desktop PC running Windows XP, or 7, my "Hello 
World" runs as expected.

The embedded PC is currently running a full installation of Windows XP 
Professional, SP3. It does so quite happily. It's CPU is DM&P Vortex86MX+ 
933MHz. I am able to run a "Hello World" program compiled with a native 
Windows compiler on it successfully.

In discussing this with the embedded PC supplier, he suggests that the 
cygwin1.dll is exiting because it doesn't recognise the CPU. Is this 
explanation plausible? And if it is, is there a solution available, or 
must I give up on using cygwin for this application?

Thanks for yout time.

Colin


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[René Berber]

On 4/2/2014 5:03 PM, Colin wrote:
 > Hi Team,

Team?   This is a user's forum.

[snip]
 > The problem I have can be reduced to this: I compile a simple "Hello
 > World" console mode c program. I copy the .exe file and cygwin1.dll onto
 > an embedded PC, open a console window, and run the program. The program
 > runs, and returns immediately to the command prompt, with no output. No
 > error messages, no nothing...

What you usually do on those cases:

1. On the build host, run ldd (or cygcheck) on the program, see the full 
list of dynamic libraries used.

2. Try to do the same on the target host.  Yes, ldd does depend on 
cygwin1.dll, so it may not run.  cygcheck doesn't depend on the 
cygwin1.dll .

 > I can do the same on any desktop PC running Windows XP, or 7, my "Hello
 > World" runs as expected.

For completeness sake, you mean a PC where Cygwin has not been installed?

 > The embedded PC is currently running a full installation of Windows XP
 > Professional, SP3. It does so quite happily. It's CPU is DM&P Vortex86MX+
 > 933MHz. I am able to run a "Hello World" program compiled with a native
 > Windows compiler on it successfully.
 >
 > In discussing this with the embedded PC supplier, he suggests that the
 > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this
 > explanation plausible?

I don't know, but I doubt it.  As long as it is compatible with the 
Intel x86 architecture, and Windows is a "complete" version, it should work.

 > And if it is, is there a solution available, or
 > must I give up on using cygwin for this application?

Cross-compilation from Cygwin to Win32 (MinGW, MinGW-w64) is still 
possible, just needs a different set of tools which are available in the 
Cygwin distributed packages.  Actually is a better option in your case, 
unless you really want to use a long list of libraries which may not be 
ported to Win32, or build programs intended for Unix/Linux.
-- 
René Berber


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

René Berber <r.berber <at> computer.org> writes:
 
> 
> What you usually do on those cases:
> 
> 1. On the build host, run ldd (or cygcheck) on the program, see the full 
> list of dynamic libraries used.
> 
> 2. Try to do the same on the target host.  Yes, ldd does depend on 
> cygwin1.dll, so it may not run.  cygcheck doesn't depend on the 
> cygwin1.dll .
 
I'll do some more of this next week when back at work. I did do cygcheck -s 
-v -r on the target (from the Cygwin Reporting Problems page) but it 
produced no output.

>  > I can do the same on any desktop PC running Windows XP, or 7, my "Hello
>  > World" runs as expected.
> 
> For completeness sake, you mean a PC where Cygwin has not been installed?

That is correct

> 
>  > In discussing this with the embedded PC supplier, he suggests that the
>  > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this
>  > explanation plausible?
> 
> I don't know, but I doubt it.  As long as it is compatible with the 
> Intel x86 architecture, and Windows is a "complete" version, it should 
work.

That is what I had expected...

> 
> Cross-compilation from Cygwin to Win32 (MinGW, MinGW-w64) is still 
> possible, just needs a different set of tools which are available in the 
> Cygwin distributed packages.  Actually is a better option in your case, 
> unless you really want to use a long list of libraries which may not be 
> ported to Win32, or build programs intended for Unix/Linux.

My reason for using Cygwin was so as to re-use code originally written for 
Linux with POSIX serial ports etc.

Thank you for your help.



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

On Apr  2 23:03, Colin wrote:
> Hi Team,
> 
> I'm new here, but have dabbled in Cygwin for a few years. I hope someone 
> more knowledgeable than myself can help with with this issue which is 
> quite frankly baffling me for the past few weeks.
> 
> The problem I have can be reduced to this: I compile a simple "Hello 
> World" console mode c program. I copy the .exe file and cygwin1.dll onto 
> an embedded PC, open a console window, and run the program. The program 
> runs, and returns immediately to the command prompt, with no output. No 
> error messages, no nothing...
> 
> I can do the same on any desktop PC running Windows XP, or 7, my "Hello 
> World" runs as expected.
> 
> The embedded PC is currently running a full installation of Windows XP 
> Professional, SP3. It does so quite happily. It's CPU is DM&P Vortex86MX+ 
> 933MHz. I am able to run a "Hello World" program compiled with a native 
> Windows compiler on it successfully.

I had a quick look into the programmer's manual for this CPU, and per
this document the CPU is i486DX compatible.  This could be the problem.
The Cygwin GCC defaults to i686 for a long time and naturally the Cygwin
DLL as well as your own application are built for i686.

> In discussing this with the embedded PC supplier, he suggests that the 
> cygwin1.dll is exiting because it doesn't recognise the CPU. Is this 
> explanation plausible? And if it is, is there a solution available, or 
> must I give up on using cygwin for this application?

As far as the pre-built Cygwin goes, I fear that you can't do a lot.
You could try to build Cygwin in i486 mode, and if that works, you have
to make sure to build applications against the newly built crt0.o and
libcygwin.a.  But that's not all to keep in mind.  When building
applications, parts of GCC are linked in as well, namely crtbegin.o and
crtend.o, and sometimes cyggcc_s-1.dll.  All these may or may not use
post-i486 opcodes, so if push comes to shove you'd end up having to
rebuild GCC for i486 as well.

I'm not trying to discourage you, but you might have a lot of
experimenting to do to get this working.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> > In discussing this with the embedded PC supplier, he suggests that the 
> > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this 
> > explanation plausible? And if it is, is there a solution available, or 
> > must I give up on using cygwin for this application?
> 
> As far as the pre-built Cygwin goes, I fear that you can't do a lot.
> You could try to build Cygwin in i486 mode, and if that works, you have
> to make sure to build applications against the newly built crt0.o and
> libcygwin.a.  But that's not all to keep in mind.  When building
> applications, parts of GCC are linked in as well, namely crtbegin.o and
> crtend.o, and sometimes cyggcc_s-1.dll.  All these may or may not use
> post-i486 opcodes, so if push comes to shove you'd end up having to
> rebuild GCC for i486 as well.
> 
> I'm not trying to discourage you, but you might have a lot of
> experimenting to do to get this working.
> 
> Corinna
> 
Thanks Corinna for this information. Now I understand the underlying issue 
and can decide how to move forward. 

Given that my application is not so big, I suspect that the pragmatic 
course will be to re-code it for Win32. 

Cheers, Colin




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

On Apr  4 09:44, Colin wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 
> > > In discussing this with the embedded PC supplier, he suggests that the 
> > > cygwin1.dll is exiting because it doesn't recognise the CPU. Is this 
> > > explanation plausible? And if it is, is there a solution available, or 
> > > must I give up on using cygwin for this application?
> > 
> > As far as the pre-built Cygwin goes, I fear that you can't do a lot.
> > You could try to build Cygwin in i486 mode, and if that works, you have
> > to make sure to build applications against the newly built crt0.o and
> > libcygwin.a.  But that's not all to keep in mind.  When building
> > applications, parts of GCC are linked in as well, namely crtbegin.o and
> > crtend.o, and sometimes cyggcc_s-1.dll.  All these may or may not use
> > post-i486 opcodes, so if push comes to shove you'd end up having to
> > rebuild GCC for i486 as well.
> > 
> > I'm not trying to discourage you, but you might have a lot of
> > experimenting to do to get this working.
> > 
> > Corinna
> > 
> Thanks Corinna for this information. Now I understand the underlying issue 
> and can decide how to move forward. 
> 
> Given that my application is not so big, I suspect that the pragmatic 
> course will be to re-code it for Win32. 

Alternatively, even though I hate to point people to older versions
of Cygwin, you could try the old Cygwin 1.5.25.  I'm not quite sure,
but I think it was compiled for i586 or even i386.  It's not as
feature-rich as Cygwin 1.7 but it worked, and maybe the set of
POSIX functions is sufficient for you.  See the Cygwin time machine
at http://www.fruitbat.org/Cygwin/index.html#cygwincirca

If you want to go even further back in time, then MSYS may be the
right thing for you.  It's a rip-off of Cygwin 1.3.22 with a few
patches to supposedly building native executables a bit better.
Just make sure to grab the old MSYS, not the more recent MSYS2.
See http://www.mingw.org/wiki/MSYS


HTH,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> 
> On Apr  4 09:44, Colin wrote:
> > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > 
> 
> Alternatively, even though I hate to point people to older versions
> of Cygwin, you could try the old Cygwin 1.5.25.  I'm not quite sure,
> but I think it was compiled for i586 or even i386.  It's not as
> feature-rich as Cygwin 1.7 but it worked, and maybe the set of
> POSIX functions is sufficient for you.  See the Cygwin time machine
> at http://www.fruitbat.org/Cygwin/index.html#cygwincirca
> 
> If you want to go even further back in time, then MSYS may be the
> right thing for you.  It's a rip-off of Cygwin 1.3.22 with a few
> patches to supposedly building native executables a bit better.
> Just make sure to grab the old MSYS, not the more recent MSYS2.
> See http://www.mingw.org/wiki/MSYS
> 
> HTH,
> Corinna
> 

Cygwin 1.5.25 seems like a good option. So I downloaded setup-legacy.exe 
from fruitbat and ran it on an XP machine which has not previously seen 
Cygwin. Initially I installed just the base Cygwin files. The process ran 
as expected, and installed 4,263 files in 472 folders. 

However the bash shell appears non-functional as far as external commands 
go. It presents a prompt bash-3.2$, if I type something like ls, it 
responds command not found. Any ideas?

Colin




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Apr  7 11:08, Colin wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> 
> > 
> > On Apr  4 09:44, Colin wrote:
> > > Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > > 
> > 
> > Alternatively, even though I hate to point people to older versions
> > of Cygwin, you could try the old Cygwin 1.5.25.  I'm not quite sure,
> > but I think it was compiled for i586 or even i386.  It's not as
> > feature-rich as Cygwin 1.7 but it worked, and maybe the set of
> > POSIX functions is sufficient for you.  See the Cygwin time machine
> > at http://www.fruitbat.org/Cygwin/index.html#cygwincirca
> > 
> > If you want to go even further back in time, then MSYS may be the
> > right thing for you.  It's a rip-off of Cygwin 1.3.22 with a few
> > patches to supposedly building native executables a bit better.
> > Just make sure to grab the old MSYS, not the more recent MSYS2.
> > See http://www.mingw.org/wiki/MSYS
> > 
> > HTH,
> > Corinna
> > 
> 
> Cygwin 1.5.25 seems like a good option. So I downloaded setup-legacy.exe 
> from fruitbat and ran it on an XP machine which has not previously seen 
> Cygwin. Initially I installed just the base Cygwin files. The process ran 
> as expected, and installed 4,263 files in 472 folders. 
> 
> However the bash shell appears non-functional as far as external commands 
> go. It presents a prompt bash-3.2$, if I type something like ls, it 
> responds command not found. Any ideas?

$PATH?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Larry Hall (Cygwin)]

On 4/7/2014 7:23 AM, Corinna Vinschen wrote:
> On Apr  7 11:08, Colin wrote:
>> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>>
>>>
>>> On Apr  4 09:44, Colin wrote:
>>>> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
>>>>
>>>
>>> Alternatively, even though I hate to point people to older versions
>>> of Cygwin, you could try the old Cygwin 1.5.25.  I'm not quite sure,
>>> but I think it was compiled for i586 or even i386.  It's not as
>>> feature-rich as Cygwin 1.7 but it worked, and maybe the set of
>>> POSIX functions is sufficient for you.  See the Cygwin time machine
>>> at http://www.fruitbat.org/Cygwin/index.html#cygwincirca
>>>
>>> If you want to go even further back in time, then MSYS may be the
>>> right thing for you.  It's a rip-off of Cygwin 1.3.22 with a few
>>> patches to supposedly building native executables a bit better.
>>> Just make sure to grab the old MSYS, not the more recent MSYS2.
>>> See http://www.mingw.org/wiki/MSYS
>>>
>>> HTH,
>>> Corinna
>>>
>>
>> Cygwin 1.5.25 seems like a good option. So I downloaded setup-legacy.exe
>> from fruitbat and ran it on an XP machine which has not previously seen
>> Cygwin. Initially I installed just the base Cygwin files. The process ran
>> as expected, and installed 4,263 files in 472 folders.
>>
>> However the bash shell appears non-functional as far as external commands
>> go. It presents a prompt bash-3.2$, if I type something like ls, it
>> responds command not found. Any ideas?
>
> $PATH?

Indeed.  And if your path under bash doesn't include /usr/bin, then I'll
wager your postinstall scripts didn't run or at least completely/correctly.
See /etc/postinstall for the scripts.  If you aren't able to figure out
what didn't run properly, you can either try rerunning everything manually
and looking for faults (if any) or just rerun setup.exe and hope that it
has better luck with the scripts the second time around.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

Larry Hall (Cygwin <reply-to-list-only-lh <at> cygwin.com> writes:

 >>>
> >>
> >> Cygwin 1.5.25 seems like a good option. So I downloaded setup-
legacy.exe
> >> from fruitbat and ran it on an XP machine which has not previously 
seen
> >> Cygwin. Initially I installed just the base Cygwin files. The process 
ran
> >> as expected, and installed 4,263 files in 472 folders.
> >>
> >> However the bash shell appears non-functional as far as external 
commands
> >> go. It presents a prompt bash-3.2$, if I type something like ls, it
> >> responds command not found. Any ideas?
> >
> > $PATH?
> 
> Indeed.  And if your path under bash doesn't include /usr/bin, then I'll
> wager your postinstall scripts didn't run or at least 
completely/correctly.
> See /etc/postinstall for the scripts.  If you aren't able to figure out
> what didn't run properly, you can either try rerunning everything 
manually
> and looking for faults (if any) or just rerun setup.exe and hope that it
> has better luck with the scripts the second time around.
> 

Spot on, Larry. $PATH is empty.
I 'Reinstall'ed Cygwin, but the result is the same. I did take note of 
setup complaining that there is a more recent version available according 
to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem.

/etc/postinstall contains the following "done" script files:
base-files-mketc.sh.done
base-files-profile.sh.done
bash.sh.done
coreutils.sh.done
cygwin-doc.sh.done
man.sh.done
passwd-grp.sh.done
terminfo.sh.done
terminfo0.sh.done
update-info-dir.sh.done

Is there something missing from that list? What's my next step? I haven't 
yet tried running them manually, that will have to wait until tonight (gmt 
+ 12).

Thanks, Colin





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Larry Hall (Cygwin)]

On 4/7/2014 5:09 PM, Colin wrote:

<snip>

>> Indeed.  And if your path under bash doesn't include /usr/bin, then I'll
>> wager your postinstall scripts didn't run or at least
> completely/correctly.
>> See /etc/postinstall for the scripts.  If you aren't able to figure out
>> what didn't run properly, you can either try rerunning everything
> manually
>> and looking for faults (if any) or just rerun setup.exe and hope that it
>> has better luck with the scripts the second time around.
>>
>
> Spot on, Larry. $PATH is empty.
> I 'Reinstall'ed Cygwin, but the result is the same. I did take note of
> setup complaining that there is a more recent version available according
> to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem.

I do find it interesting that the Cygwin Time Machine wouldn't have the
setup version and the archive in sync.  You'd have to check with that site
to understand why you're seeing that.

> /etc/postinstall contains the following "done" script files:
> base-files-mketc.sh.done
> base-files-profile.sh.done
> bash.sh.done
> coreutils.sh.done
> cygwin-doc.sh.done
> man.sh.done
> passwd-grp.sh.done
> terminfo.sh.done
> terminfo0.sh.done
> update-info-dir.sh.done
>
> Is there something missing from that list? What's my next step? I haven't
> yet tried running them manually, that will have to wait until tonight (gmt
> + 12).

That list seems a bit limited to me, unless you specifically asked for just
those packages to install.  Allowing setup to install a default installation
should get you several dozen packages I believe, in 1.5 days.  So I'd say
start there and check that.  If that doesn't help, check with the Cygwin
Time Machine site for help.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Peter A. Castro]

On Mon, 7 Apr 2014, Larry Hall (Cygwin) wrote:
> On 4/7/2014 5:09 PM, Colin wrote:
>
> <snip>
>
>>> Indeed.  And if your path under bash doesn't include /usr/bin, then I'll
>>> wager your postinstall scripts didn't run or at least
>> completely/correctly.
>>> See /etc/postinstall for the scripts.  If you aren't able to figure out
>>> what didn't run properly, you can either try rerunning everything
>> manually
>>> and looking for faults (if any) or just rerun setup.exe and hope that it
>>> has better luck with the scripts the second time around.
>>> 
>> 
>> Spot on, Larry. $PATH is empty.
>> I 'Reinstall'ed Cygwin, but the result is the same. I did take note of
>> setup complaining that there is a more recent version available according
>> to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem.
>
> I do find it interesting that the Cygwin Time Machine wouldn't have the
> setup version and the archive in sync.  You'd have to check with that site
> to understand why you're seeing that.

Geetings, Larry,

Some comments about this (sorry if this is off-tipic):

1) There used to be a directory to pull the snapshots, but that's been
    removed or otherwise made inaccessable a while ago, so archving the
    snapshots has been impossible for me.

2) Packaging changes of setup.exe have made extracting the version string
    impossible, save for actually running setup, which isn't something I'm
    going to do on a daily basis.  If there is a method of extracting this
    info from it, please do tell me how.

3) The format of setup.ini hasn't changed in any significant way that
    prevents newer versions of setup from working with older versions of
    the achive, and vise-versa, so it hasn't been worth doing regular
    achives of setup.  Mostly I tell people to grab the lastest setup and
    try it first.

    The exceptions are for the Legacy release (hard coded for -legacy)
    as well as the preview (-2) release, but that, again, was most about
    the name of the setup file and the initial release path names.
    So, there really hasn't been much incentive to archive setup.

    That being said, I do have a Legacy and a -2 setup versions available
    for those that need them, as well as some other older releases of
    setup, just in case.

    If someone can tell me how to extract the version id from setup.exe,
    I'll start archiving specific versions of it again.

>> /etc/postinstall contains the following "done" script files:
>> base-files-mketc.sh.done
>> base-files-profile.sh.done
>> bash.sh.done
>> coreutils.sh.done
>> cygwin-doc.sh.done
>> man.sh.done
>> passwd-grp.sh.done
>> terminfo.sh.done
>> terminfo0.sh.done
>> update-info-dir.sh.done
>> 
>> Is there something missing from that list? What's my next step? I haven't
>> yet tried running them manually, that will have to wait until tonight (gmt
>> + 12).
>
> That list seems a bit limited to me, unless you specifically asked for just
> those packages to install.  Allowing setup to install a default installation
> should get you several dozen packages I believe, in 1.5 days.  So I'd say
> start there and check that.  If that doesn't help, check with the Cygwin
> Time Machine site for help.

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Larry Hall (Cygwin)]

On 4/7/2014 6:41 PM, Peter A. Castro wrote:
<snip>

> Geetings, Larry,
>
> Some comments about this (sorry if this is off-tipic):

Since you're providing this Cygwin service, I don't consider information
about this service to be off-topic.  And, of course, if *I* don't consider
it off-topic, it certainly can't be. ;-)

> 1) There used to be a directory to pull the snapshots, but that's been
>     removed or otherwise made inaccessable a while ago, so archving the
>     snapshots has been impossible for me.

Understood.  Yeah, access to "snapshots", among others, is turned off to
robots.  I'd say check with Chris on this one to see if there could be
some accommodation here.

> 2) Packaging changes of setup.exe have made extracting the version string
>     impossible, save for actually running setup, which isn't something I'm
>     going to do on a daily basis.  If there is a method of extracting this
>     info from it, please do tell me how.

I'm assuming it used to just be in the RC file in the past.  Didn't look
in the history to trace it back.  But now it is generated and put in
setup_version.c as a global constant setup_version.

> 3) The format of setup.ini hasn't changed in any significant way that
>     prevents newer versions of setup from working with older versions of
>     the achive, and vise-versa, so it hasn't been worth doing regular
>     achives of setup.  Mostly I tell people to grab the lastest setup and
>     try it first.

Yes, generally, this should work and I agree that this is the first,
easiest answer if there is no corresponding setup for a particular date.  I
was under the impression that you were also pulling setups with each
release.  That, of course, is no guarantee of direct correspondence
either but it's close.  No matter.

>     The exceptions are for the Legacy release (hard coded for -legacy)
>     as well as the preview (-2) release, but that, again, was most about
>     the name of the setup file and the initial release path names.
>     So, there really hasn't been much incentive to archive setup.
>
>     That being said, I do have a Legacy and a -2 setup versions available
>     for those that need them, as well as some other older releases of
>     setup, just in case.

Yes, I noticed.  That's a "Good Thing"(tm).  :-)

Thanks,


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Christopher Faylor]

On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
>On 4/7/2014 6:41 PM, Peter A. Castro wrote:
><snip>
>
>> Geetings, Larry,
>>
>> Some comments about this (sorry if this is off-tipic):
>
>Since you're providing this Cygwin service, I don't consider information
>about this service to be off-topic.  And, of course, if *I* don't consider
>it off-topic, it certainly can't be. ;-)
>
>> 1) There used to be a directory to pull the snapshots, but that's been
>>     removed or otherwise made inaccessable a while ago, so archving the
>>     snapshots has been impossible for me.
>
>Understood.  Yeah, access to "snapshots", among others, is turned off to
>robots.  I'd say check with Chris on this one to see if there could be
>some accommodation here.

The only thing that has changed in the last year is that the snapshots
are now in an architecture specific directory.  I'm not aware of
sourceware offering any method for accessing snapshots other than the
snapshot web page.

>> 2) Packaging changes of setup.exe have made extracting the version string
>>     impossible, save for actually running setup, which isn't something I'm
>>     going to do on a daily basis.  If there is a method of extracting this
>>     info from it, please do tell me how.
>
>I'm assuming it used to just be in the RC file in the past.  Didn't look
>in the history to trace it back.  But now it is generated and put in
>setup_version.c as a global constant setup_version.

setup.exe is packed with upx.  If you want to see the version string I
suppose you could unpack it with upx.

>> 3) The format of setup.ini hasn't changed in any significant way that
>>     prevents newer versions of setup from working with older versions of
>>     the achive, and vise-versa, so it hasn't been worth doing regular
>>     achives of setup.  Mostly I tell people to grab the lastest setup and
>>     try it first.
>
>Yes, generally, this should work and I agree that this is the first,
>easiest answer if there is no corresponding setup for a particular date.  I
>was under the impression that you were also pulling setups with each
>release.  That, of course, is no guarantee of direct correspondence
>either but it's close.  No matter.

It is entirely possible that a new field could show up in setup.ini
eventually but I don't see the syntax changing so it's likely, but
not guaranteed, that new setup.exe's will work with old setup.ini's.

>>     The exceptions are for the Legacy release (hard coded for -legacy)
>>     as well as the preview (-2) release, but that, again, was most about
>>     the name of the setup file and the initial release path names.
>>     So, there really hasn't been much incentive to archive setup.
>>
>>     That being said, I do have a Legacy and a -2 setup versions available
>>     for those that need them, as well as some other older releases of
>>     setup, just in case.
>
>Yes, I noticed.  That's a "Good Thing"(tm).  :-)
>
>Thanks,
>
>
>-- 
>Larry
>
>_____________________________________________________________________
>
>A: Yes.
> > Q: Are you sure?
> >> A: Because it reverses the logical flow of conversation.
> >>> Q: Why is top posting annoying in email?
>
>--
>Problem reports:       http://cygwin.com/problems.html
>FAQ:                   http://cygwin.com/faq/
>Documentation:         http://cygwin.com/docs.html
>Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Larry Hall (Cygwin)]

On 4/7/2014 9:50 PM, Christopher Faylor wrote:
> On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:

<snip>

>>> 2) Packaging changes of setup.exe have made extracting the version string
>>>      impossible, save for actually running setup, which isn't something I'm
>>>      going to do on a daily basis.  If there is a method of extracting this
>>>      info from it, please do tell me how.
>>
>> I'm assuming it used to just be in the RC file in the past.  Didn't look
>> in the history to trace it back.  But now it is generated and put in
>> setup_version.c as a global constant setup_version.
>
> setup.exe is packed with upx.  If you want to see the version string I
> suppose you could unpack it with upx.

Of course!  Why didn't I think of that?

strings setup*.exe | grep setup-version

This returns the version for a _decompressed_ setup executable.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Peter A. Castro]

On Mon, 7 Apr 2014, Larry Hall (Cygwin) wrote:

> On 4/7/2014 9:50 PM, Christopher Faylor wrote:
>> On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
>
> <snip>
>
>>>> 2) Packaging changes of setup.exe have made extracting the version string
>>>>      impossible, save for actually running setup, which isn't something 
>>>> I'm
>>>>      going to do on a daily basis.  If there is a method of extracting 
>>>> this
>>>>      info from it, please do tell me how.
>>> 
>>> I'm assuming it used to just be in the RC file in the past.  Didn't look
>>> in the history to trace it back.  But now it is generated and put in
>>> setup_version.c as a global constant setup_version.
>> 
>> setup.exe is packed with upx.  If you want to see the version string I
>> suppose you could unpack it with upx.
>
> Of course!  Why didn't I think of that?
>
> strings setup*.exe | grep setup-version
>
> This returns the version for a _decompressed_ setup executable.

This is, in fact, what I was doing before there was a change in the packer 
utility that I was unable to, at the time. build for myself.

I've just built a newer version of upx (and ucl, etc) and now I will start 
archiving setup, x86 & x86_64, (again).  Need to update my webpage 
automation to generate an access list, but atleast I'm grabbing and 
archiving them (again).

Thanks for bringing this (back) to my attention (again).

In general, though, unless and until there is a significant change to 
the setup.ini format, the most recent installer *should* just work.

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Achim Gratz]

Peter A. Castro <doctor <at> fruitbat.org> writes:
> I've just built a newer version of upx (and ucl, etc) and now I will start 
> archiving setup, x86 & x86_64, (again).  Need to update my webpage 
> automation to generate an access list, but atleast I'm grabbing and 
> archiving them (again).

Not that I want to discourage you from building those yourself, but I should
perhaps mention that these packages are current for both Cygwin32 and Cygwin64.


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Peter A. Castro]

On Wed, 16 Apr 2014, Achim Gratz wrote:

> Peter A. Castro writes:
>> I've just built a newer version of upx (and ucl, etc) and now I will start
>> archiving setup, x86 & x86_64, (again).  Need to update my webpage
>> automation to generate an access list, but atleast I'm grabbing and
>> archiving them (again).

Greetings, Achim,

> Not that I want to discourage you from building those yourself, but I should
> perhaps mention that these packages are current for both Cygwin32 and Cygwin64.

Ah.  You are making the assumption I'm running my little project
(Cygwin Time Machine) on Windows?  No.  This is run on a Linux server I 
use (heresy, I know :-), mostly using automated scripts and cron jobs.

As entertaining an idea of running Cygwin's upx.exe under Wine, just to
unpack setup, might seem, I felt it was a bit of overkill.  :-) So, I
needed to build upx natively in order to unpack setup.

When I tried this years ago, it didn't compile and I didn't have time to
persue it.  But the recent versions of upx (and ucl) both compile & run
just fine.

> Regards,
> Achim.

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Achim Gratz]

Peter A. Castro writes:
> Ah.  You are making the assumption I'm running my little project
> (Cygwin Time Machine) on Windows?  No.  This is run on a Linux server
> I use (heresy, I know :-), mostly using automated scripts and cron
> jobs.

I just wanted to avoid folks asking for those "new" versions on Cygwin
when they are already here.  I certainly didn't want to suggest you do
or should run your server on Windows.  :-)

> When I tried this years ago, it didn't compile and I didn't have time to
> persue it.  But the recent versions of upx (and ucl) both compile & run
> just fine.

Yes, it just builds out-of-the-box now.  All software should do that!


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Peter A. Castro]

On Mon, 7 Apr 2014, Christopher Faylor wrote:

Greetings, Chris,

> On Mon, Apr 07, 2014 at 09:28:29PM -0400, Larry Hall (Cygwin) wrote:
>> On 4/7/2014 6:41 PM, Peter A. Castro wrote:
>> <snip>
>>
>>> Geetings, Larry,
>>>
>>> Some comments about this (sorry if this is off-tipic):
>>
>> Since you're providing this Cygwin service, I don't consider information
>> about this service to be off-topic.  And, of course, if *I* don't consider
>> it off-topic, it certainly can't be. ;-)

Good to know! :-)

>>> 1) There used to be a directory to pull the snapshots, but that's been
>>>     removed or otherwise made inaccessable a while ago, so archving the
>>>     snapshots has been impossible for me.
>>
>> Understood.  Yeah, access to "snapshots", among others, is turned off to
>> robots.  I'd say check with Chris on this one to see if there could be
>> some accommodation here.
>
> The only thing that has changed in the last year is that the snapshots
> are now in an architecture specific directory.  I'm not aware of
> sourceware offering any method for accessing snapshots other than the
> snapshot web page.

Hmm... Perhaps I've been trying to wget the wrong directory.  I'll check 
on that and get back to you.

>>> 2) Packaging changes of setup.exe have made extracting the version string
>>>     impossible, save for actually running setup, which isn't something I'm
>>>     going to do on a daily basis.  If there is a method of extracting this
>>>     info from it, please do tell me how.
>>
>> I'm assuming it used to just be in the RC file in the past.  Didn't look
>> in the history to trace it back.  But now it is generated and put in
>> setup_version.c as a global constant setup_version.
>
> setup.exe is packed with upx.  If you want to see the version string I
> suppose you could unpack it with upx.

I have an old version of upx, so perhaps it's just out of date, but even 
when I could extract it, at some point the version string was moved to 
setup_version.c and became difficult to extract from the binary.  I'd 
largely given up, but I'll take another crack at it.

>>> 3) The format of setup.ini hasn't changed in any significant way that
>>>     prevents newer versions of setup from working with older versions of
>>>     the achive, and vise-versa, so it hasn't been worth doing regular
>>>     achives of setup.  Mostly I tell people to grab the lastest setup and
>>>     try it first.
>>
>> Yes, generally, this should work and I agree that this is the first,
>> easiest answer if there is no corresponding setup for a particular date.  I
>> was under the impression that you were also pulling setups with each
>> release.  That, of course, is no guarantee of direct correspondence
>> either but it's close.  No matter.
>
> It is entirely possible that a new field could show up in setup.ini
> eventually but I don't see the syntax changing so it's likely, but
> not guaranteed, that new setup.exe's will work with old setup.ini's.

Yes, there's no guarantee, I knowledge that.

That's why I randomly keep a copy of various versions of setup, just in 
case.  But, until something does change, it "WJFFM".  :-)

Once I have an ability to extract versions from setup again, I'll see 
about doing it more regularly.

>>>     The exceptions are for the Legacy release (hard coded for -legacy)
>>>     as well as the preview (-2) release, but that, again, was most about
>>>     the name of the setup file and the initial release path names.
>>>     So, there really hasn't been much incentive to archive setup.
>>>
>>>     That being said, I do have a Legacy and a -2 setup versions available
>>>     for those that need them, as well as some other older releases of
>>>     setup, just in case.
>>
>> Yes, I noticed.  That's a "Good Thing"(tm).  :-)
>>
>> Thanks,

Thanks, to both of you, for replying.  I really apprecite it.

>> --
>> Larry
>>
>> _____________________________________________________________________
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

-- 
--=> Peter A. Castro
Email: doctor at fruitbat dot org / Peter dot Castro at oracle dot com
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Duncan Roe]

On Mon, Apr 07, 2014 at 06:12:56PM -0400, Larry Hall (Cygwin) wrote:
> On 4/7/2014 5:09 PM, Colin wrote:
>
> <snip>
>
> >>Indeed.  And if your path under bash doesn't include /usr/bin, then I'll
> >>wager your postinstall scripts didn't run or at least
> >completely/correctly.
> >>See /etc/postinstall for the scripts.  If you aren't able to figure out
> >>what didn't run properly, you can either try rerunning everything
> >manually
> >>and looking for faults (if any) or just rerun setup.exe and hope that it
> >>has better luck with the scripts the second time around.
> >>
> >
> >Spot on, Larry. $PATH is empty.
> >I 'Reinstall'ed Cygwin, but the result is the same. I did take note of
> >setup complaining that there is a more recent version available according
> >to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem.
>
> I do find it interesting that the Cygwin Time Machine wouldn't have the
> setup version and the archive in sync.  You'd have to check with that site
> to understand why you're seeing that.
>
> >/etc/postinstall contains the following "done" script files:
> >base-files-mketc.sh.done
> >base-files-profile.sh.done
> >bash.sh.done
> >coreutils.sh.done
> >cygwin-doc.sh.done
> >man.sh.done
> >passwd-grp.sh.done
> >terminfo.sh.done
> >terminfo0.sh.done
> >update-info-dir.sh.done
> >
> >Is there something missing from that list? What's my next step? I haven't
> >yet tried running them manually, that will have to wait until tonight (gmt
> >+ 12).
>
> That list seems a bit limited to me, unless you specifically asked for just
> those packages to install.  Allowing setup to install a default installation
> should get you several dozen packages I believe, in 1.5 days.  So I'd say
> start there and check that.  If that doesn't help, check with the Cygwin
> Time Machine site for help.
>
I have an older install at work, and thought that behaviour was normal (empty
$PATH).  I just set the PATH in .bashrc in the initial directory - then
everything "just worked".

Cheers ... Duncan.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

Larry Hall (Cygwin <reply-to-list-only-lh <at> cygwin.com> writes:

> 
> On 4/7/2014 5:09 PM, Colin wrote:
> 
> <snip>
> 
> >> Indeed.  And if your path under bash doesn't include /usr/bin, then 
I'll
> >> wager your postinstall scripts didn't run or at least
> > completely/correctly.
> >> See /etc/postinstall for the scripts.  If you aren't able to figure out
> >> what didn't run properly, you can either try rerunning everything
> > manually
> >> and looking for faults (if any) or just rerun setup.exe and hope that 
it
> >> has better luck with the scripts the second time around.
> >>
> >
> > Spot on, Larry. $PATH is empty.
> > I 'Reinstall'ed Cygwin, but the result is the same. I did take note of
> > setup complaining that there is a more recent version available 
according
> > to the ini file (2.774 vs 2.674) but I'm picking that isn't the problem.
> 
> I do find it interesting that the Cygwin Time Machine wouldn't have the
> setup version and the archive in sync.  You'd have to check with that site
> to understand why you're seeing that.
> 
> > /etc/postinstall contains the following "done" script files:
> > base-files-mketc.sh.done
> > base-files-profile.sh.done
> > bash.sh.done
> > coreutils.sh.done
> > cygwin-doc.sh.done
> > man.sh.done
> > passwd-grp.sh.done
> > terminfo.sh.done
> > terminfo0.sh.done
> > update-info-dir.sh.done
> >
> > Is there something missing from that list? What's my next step? I 
haven't
> > yet tried running them manually, that will have to wait until tonight 
(gmt
> > + 12).
> 
> That list seems a bit limited to me, unless you specifically asked for 
just
> those packages to install.  Allowing setup to install a default 
installation
> should get you several dozen packages I believe, in 1.5 days.  So I'd say
> start there and check that.  If that doesn't help, check with the Cygwin
> Time Machine site for help.
> 

Examination of the install log files revealed that the post-install scripts 
all failed to execute correctly, with directory and file not found errors.

For the record, I found that if installing to the root directory (normally 
not recommended) that it all works.

And yes, my initial goal of compiling an application that will run on the 
Vortex86MX+ cpu has finally been achieved.

My grateful thanks to all who have offered advice.

Colin





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Yaakov (Cygwin/X)]

On 2014-04-02 18:03, Colin wrote:
> The problem I have can be reduced to this: I compile a simple "Hello
> World" console mode c program. I copy the .exe file and cygwin1.dll onto
> an embedded PC, open a console window, and run the program. The program
> runs, and returns immediately to the command prompt, with no output. No
> error messages, no nothing...
>
> The embedded PC is currently running a full installation of Windows XP
> Professional, SP3. It does so quite happily. It's CPU is DM&P Vortex86MX+
> 933MHz. I am able to run a "Hello World" program compiled with a native
> Windows compiler on it successfully.
>
> In discussing this with the embedded PC supplier, he suggests that the
> cygwin1.dll is exiting because it doesn't recognise the CPU.

Actually, if Wikipedia[1] is correct (yes, yes, I know), the problem is 
that the CPU doesn't recognize the code.  Apparently, these CPUs are 
missing the CMOV instruction used when compiling with gcc -march=i686, 
which has been the default setting for the Cygwin x86 compilers for 
several years now.

Therefore, in order to even attempt to make this work, you would have to 
recompile gcc for -march=i586 default, then rebuild *everything* with 
that gcc; but I can't guarantee that there won't be other issues as well.


Yaakov

[1] https://en.wikipedia.org/wiki/Vortex86#CPU


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Trouble with running cygwin dll on Vortex86MX+ CPU

[Colin]

Yaakov (Cygwin/X <yselkowitz <at> users.sourceforge.net> writes:

> 
> Therefore, in order to even attempt to make this work, you would have to 
> recompile gcc for -march=i586 default, then rebuild *everything* with 
> that gcc; but I can't guarantee that there won't be other issues as well.
> 
> Yaakov
> 
> [1] https://en.wikipedia.org/wiki/Vortex86#CPU
> 
> 


Thanks Yaakov.
You people on this list are awesome. I should have come here earlier...



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple