Trouble with running cygwin dll on Vortex86MX+ CPU

Peter A. Castro doctor@fruitbat.org
Tue Apr 8 02:14:00 GMT 2014


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



More information about the Cygwin mailing list