headers
Charles Wilson | 1 Mar 2011 03:16
Picon

Re: Time for native MSYS?

On 2/28/2011 4:28 AM, Michael T. wrote:
> 
>> I have heard claims that running a linux guest in a virtual machine on a
>> win32 host, and using a mingw-target cross compiler IN the linux guest,
>> is actually faster than using either MinGW/MSYS or Cygwin...
> 
> Interesting.. What particular virtual machine? Is a benchmark test available?

Don't know.  They were "claims" not "double blind scientific studies".
At this point I don't even recall where I first heard/read them.

But...if somebody actually DID do some tests like this on identical
hardware for an apples-to-apples comparison it'd sure be interesting.

--
Chuck

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.
(Continue reading)

Permalink | Reply | 1 comment |
headers
J Decker | 1 Mar 2011 03:46
Picon
Gravatar

Re: Time for native MSYS?

On Mon, Feb 28, 2011 at 6:16 PM, Charles Wilson
<cwilso11@...> wrote:
> On 2/28/2011 4:28 AM, Michael T. wrote:
>>
>>> I have heard claims that running a linux guest in a virtual machine on a
>>> win32 host, and using a mingw-target cross compiler IN the linux guest,
>>> is actually faster than using either MinGW/MSYS or Cygwin...
>>
>> Interesting.. What particular virtual machine? Is a benchmark test available?
>
> Don't know.  They were "claims" not "double blind scientific studies".
> At this point I don't even recall where I first heard/read them.
>
> But...if somebody actually DID do some tests like this on identical
> hardware for an apples-to-apples comparison it'd sure be interesting.
>

Heh that is a fact; for a long time I mainted code for linux/windows,
I just use make and gcc basically though; nothing as complex as
configure.  But certainly cygwin is the slowest like 66% speed unless
you use -mno-cygwin; msys I have no exp.; gcc and make under windows
is slower than gcc and make under linux in a vmware box on the same
computer.  The linux box SEEMS at  least 200% faster IIRC, but sadly I
don't have specific benchmarks anymore;  I could start the same
compile using basicaly the same compilers under windows and the vmware
linux and the linux box will finish ahead 100% of the time.
especially something like cmake that invokes processes repeatedly.

> --
> Chuck
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Koppe | 1 Mar 2011 08:13
Picon

Re: Time for native MSYS?

On 28 February 2011 15:12, Earnie wrote:
> Chris Wilson wrote:
>> Hi Keith and all,
>>> Well, our GCC and binutils tool chain is already 100% native.
>>
>> Does that mean that they avoid the startup overhead of loading
>> msys-1.0.dll and forking CPP? If so then perhaps I'm barking up the wrong
>> tree.
>
> The compiler and linker set are linked to msvcrt.dll and not
> msys-1.0.dll.  If you use MSYS then MSYS will need to convert the path
> strings before spawning the native application.  This is still faster
> than Cygwin because the SYMLINK code has been removed

I doubt that symlink support has much to do with any speed difference.
The biggee is fork().

> Also MSYS doesn't use the registry so you can store it on a
> USB disk, use it on any computer and not leave a footprint.

Same for Cygwin 1.7. The DLL assumes that the directory above its own
is the POSIX root directory and reads mount points from /etc/fstab.
Not sure how that's relevant to this thread though.

Andy

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael T. | 1 Mar 2011 10:45
Picon
Favicon

Re: too many header warnings

macro as follows should be used instead.
> >
> > — Macro: AC_C_INLINE
> > If the C compiler supports the keyword inline, do nothing. Otherwise
> > define inline to __inline__ or __inline if it accepts one of those,
> > otherwise define inline to be empty.
> 
> Except that the OP said his project uses cmake, not autoconf, so he
> cannot use AC_C_INLINE; I don't know if cmake provides an equivalent.
> 
> I know very little about cmake, (and what little I do know doesn't
> inspire me to learn more).  I will always choose autoconf for my
> projects, but I don't want to get embroiled in a religious war over
> which is the better choice; each project maintainer is free to make
> his or her own choice.

Cmake is OpenCV (which is a very famous computer vision library) folks' choice. As far as my research went it
was the only option to make it work on Windows.
I followed these steps http://opencv.willowgarage.com/wiki/MinGW
slightly altered to fit my mingw installation. I use the mingw "bash" to compile my stuff, not Code Blocks.

However, it seems to me that Cmake is becoming popular, but I can't say wether it's got or not.

Michael

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
(Continue reading)

Permalink | Reply | 2 comments |
headers
Keith Marshall | 1 Mar 2011 11:21
Picon

Re: too many header warnings

On 1 March 2011 09:45, Michael T. wrote:
> Cmake is OpenCV (which is a very famous computer vision library)
> folks' choice.

Which is fine.  Earnie's point still stands: the preprocesser code
fragment you posted looks wrong; the best practice for determining what
the correct implementation would be should be modelled on the autoconf
feature test technique, as implemented for the AC_C_INLINE macro.

> As far as my research went it was the only option to make it work on
> Windows.

If you are saying that you think cmake works on Windows, and autoconf
does not, then you have been sadly misled.  Autoconf works fine with
either Cygwin or MSYS, and will always be my preferred choice.

> However, it seems to me that Cmake is becoming popular, but I can't
> say wether it's got or not.

What have sheep got to do with it?  Sorry, couldn't resist: a wether is
a castrated ram; you mean 'whether', and I guess you mean 'good' rather
than 'got'. :-)

I'm sure cmake is basically a good system.  A few years ago, the cmake
maintainer approached me for info relating to MinGW/MSYS, and asked me
to comment on cmake's MinGW/MSYS implementation.  IMO, it was adequate,
but not as good as autoconf; my opinion only, and you, or anyone else,
is free to make an alternative choice.

But, we are drifting off-topic; I have no more to say on the matter.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael T. | 1 Mar 2011 12:51
Picon
Favicon

Re: too many header warnings


> > As far as my research went it was the only option to make it work on
> > Windows.
> 
> If you are saying that you think cmake works on Windows, and autoconf
> does not, then you have been sadly misled.  Autoconf works fine with
> either Cygwin or MSYS, and will always be my preferred choice.

No, I am not saying that. By *it* I meant OpenCV, that should have been clear from the context.
Autoconf would have been a preferred choice for me, too, but I didn't find such an installation option on the
OpenCV website, hence I was forced to make Cmake work on Windows to be able to compile OpenCV for my system.

> > However, it seems to me that Cmake is becoming popular, but I can't
> > say wether it's got or not.
> 
> What have sheep got to do with it?  Sorry, couldn't resist: a wether is
> a castrated ram; you mean 'whether', and I guess you mean 'good' rather
> than 'got'. :-)

Of course, but it's weird, because I always read my email once or twice before posting and I can't figure out
how *good* became *got*, perhaps it should've been goat. Goat and a wether.

> But, we are drifting off-topic; I have no more to say on the matter.

 Let us say no more.

> -- 
> Regards,
> Keith.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Albrecht Schlosser | 1 Mar 2011 13:15
Picon

Re: mingw-get upgrade for MSYS mintty and rxvt users

On 27.02.2011 13:32, Keith Marshall wrote:
> I've posted a minor upgrade to mingw-get, bringing its patch-level to
> mingw-get-0.1-alpha-5.2;
>
> This interim release provides a work-around for the improper I/O
> buffering which is apparent within the MSYS builds of mintty and rxvt;

BIG thanks, this works like a charm :-)

Albrecht

P.S. Sorry for the late response, I didn't read the ML for a few days.

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
MinGW-users mailing list
MinGW-users@...

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
(Continue reading)

Permalink | Reply | 0 comments |
headers
Albrecht Schlosser | 1 Mar 2011 13:28
Picon

OpenSSL configure [was: Re: Time for native MSYS?]

On 28.02.2011 00:18, Chris Wilson wrote:

> The project I'm working on requires OpenSSL and PCRE, both of which have
> their own non-standard configure mechanisms, and I seem to remember
> having difficulty getting them to work with MSYS (it was a long time ago).
> If someone knows that either of these works, please let me know (and if
> possible, how to do it) :)

Hmm, I don't know if you really meant OpenSSL to run *with* MSYS (i.e.
with the MSYS dll), or native. I'm sure you know that there is a current
msys-openssl package to download, but that's not up-to-date.

I needed OpenSSL for native Windows (w/o MSYS), and it turned out that
recent versions (1.0.0c) work OOTB. I used:

$ ./config no-threads --prefix=... \
   --openssldir='C:/mingw/msys/1.0/...'

Note the path in Windows notation "C:..." with forward slashes to avoid
more escaping. I also configured w/o any options, and it worked...

HTH
Albrecht

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev
(Continue reading)

Permalink | Reply | 0 comments |
headers
Earnie | 1 Mar 2011 13:46
Picon

Re: Time for native MSYS?

Andy Koppe wrote:
> On 28 February 2011 15:12, Earnie wrote:
>> Chris Wilson wrote:
>>> Hi Keith and all,
>>>> Well, our GCC and binutils tool chain is already 100% native.
>>>
>>> Does that mean that they avoid the startup overhead of loading
>>> msys-1.0.dll and forking CPP? If so then perhaps I'm barking up the wrong
>>> tree.
>>
>> The compiler and linker set are linked to msvcrt.dll and not
>> msys-1.0.dll.  If you use MSYS then MSYS will need to convert the path
>> strings before spawning the native application.  This is still faster
>> than Cygwin because the SYMLINK code has been removed
> 
> I doubt that symlink support has much to do with any speed difference.
> The biggee is fork().
> 

You can doubt all you want but your doubt isn't based on anything
factual.  In Cygwin every file is opened and read looking for a symlink
signature.  If a symlink signature is found the file referenced is then
opened and read looking for a symlink signature.  You don't think that
is slow, fine, but I will disagree.

>> Also MSYS doesn't use the registry so you can store it on a
>> USB disk, use it on any computer and not leave a footprint.
> 
> Same for Cygwin 1.7. The DLL assumes that the directory above its own
> is the POSIX root directory and reads mount points from /etc/fstab.
(Continue reading)

Permalink | Reply | 3 comments |
headers
LRN | 1 Mar 2011 16:51
Picon
Gravatar

Re: msys-perl regression

On 27.02.2011 22:02, Charles Wilson wrote:
> In any case, we might also need to bring in Reini's 'perlrebase' tool,
> which is a script like rebaseall, but invokes rebase.exe only on perl
> DLLs with some special settings for perl.
>
About rebase. I've studied its source package and have found that rebase 
can be built natively, i.e. made link against msvcrt rather than msys-1.0
This native rebase coupled with a program (also native) that does the 
same thing rebaseall script does (composes a list of files by 
recursively looking through directories for files ending with some 
prefixes and then invokes rebase), allows rebasing to be done outside of 
bash/dash or whatever and would make rebasing more complete. It could be 
also run automatically - simply make a batch file that waits a few 
seconds, kills any msys processes still running, runs rebase, re-runs 
msys-sh, making it run a particular script (which is written beforehand) 
that will restore the shell state (set env variables, cd into the right 
directory and run the right command, probably `make $something').
With such a tool it should be possible to rebase perl after it is 
compiled and before its testsuite is run - and all that would be 
completely automatic!

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
MinGW-users mailing list
MinGW-users@...
(Continue reading)

Permalink | Reply | 8 comments |

Gmane