mingw-users Mailing List for MinGW - Minimalist GNU for Windows

Chris Wilson wrote:
> Hi all,
>
>    
[snip]

ash from unmaintained  pw32 projects and bash from mingw (msys) work 
slow under windows emulation - about 10 times slower then native bash.
No idea how ash is build . It work under wine but same time crash.
msys bash work under wine since ... sorry I forgot wine version that 
resolve bash crash.
msys dash still crash under wine.

Sorry I could not help as I'm not familiar with internals of above shell 
and why all of them are so slow.
I guess that native performance is related to the windows process 
management - it is slow.


Regards,
Roumen

Hi,

just compiled pkg-config 0.25 with mingw.
Compiled out of the box (no special config flags needed) and works like 
a charm.
I used glib 2.28.

Best regards,

David
>
> Hello le,
>
>> Greetings again --
>> well no one responded to my last mail so I have continued to sift through
>> the output of make, and now I am running into a different problem:
>>
>> Instead of failing to find glib.h like it used to do, it is encountering
>> undefined symbols that should have been defined in system header files. For
>> example, SIGCHLD and all the other signals, as well as I/O constants.
> 1) LRN explained the problem. You need to define certain constants on the
> command line.
>
>> This explains why i put "-DNATIVE_WIN32" into  CFLAGS="-D_POSIX
>> -DG_OS_WIN32 -DNATIVE_WIN32 -O3 -s -mms-bitfields -mtune=generic" that
>> i've mentioned in my previous message is essential.
>
>
> You *must* configure like this:
> CFLAGS="-DG_OS_WIN32 -DNATIVE_WIN32 -O3 -s -mms-bitfields -mtune=generic" \
> ../configure --prefix=/mingw --disable-indirect-deps \
>
> [and-any-other-suggested-flags]
>
> Various sections of the code look something like this:
>
> #ifdef NATIVE_WIN32
> /* Use Windows API */
> #else
> /* Use Linux or POSIX API */
> #endif
>
> Therefore, if you define NATIVE_WIN32 as you should, then Linux code
> will not be compiled.
>
> If you understood this, and what you meant was that after changing
> your configure command to the suggested one, symbols are not being
> found, this could be caused by failing to run 'make distclean'
> before configuring again. If you want to run configure after making
> changes to the command line, you should run 'make distclean' first
> in order to delete all files produced by configure and make.
>
>> Now I realize windows doesn't use the same mechanisms as linux for handling
>> signals, so this code should probably be conditionally compiled
> And it is, or will be if you #define NATIVE_WIN32 and G_OS_WIN32.
>
>
>> I am finding I get the identical results whether I configure
>> with --disable-indirect-deps or not.
>> I don't know what this option does or why it was suggested that I use it.
> Neither do I, but evidently it is not what you need to turn on
> conditional compilation. Please don't configure without it, because
> when you get past the conditional compilation problem, you will no
> doubt run into the problem that --disable-indirect-deps fixes.
>
> If you really want to know what this flag does, run
> configure --help.
>
>
>> Meanwhile, I really need pkg-config for what I'm working on and am hoping
>> someone can point out anything that might make this build script work.
>>
> I had suggested the 32-bit pre-built pkg-config, which works just fine on
> my 64-bit Vista Home Premium SP2. Did you try it?
>
> Regards,
> Alias John Brown.
>   		 	   		
> ------------------------------------------------------------------------------
> 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
> Min...@li...
>
> 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
> Also: mailto:min...@li...?subject=unsubscribe

Keith Marshall wrote:
> On 28 February 2011 15:02, Earnie wrote:
>> Keith Marshall wrote:
>>> On 28 February 2011 12:22, Michael T. wrote:
>>>> So you're saying that mingw gcc defines both _WIN32 and __GNUC__
>>>
>>> Yes.  FWIW:
>>>
>>>   $ gcc -E -dM nul.c
>>
>> It shouldn't matter that _WIN32 or __GNUC__ is defined.  The autoconf
>> 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.
> 

Oh, well, yea, of course. I know even less than you obviously.  My point
being for pointing out AC_C_INLINE is that the correct way to determine
if a compiler can use a feature is to test the feature and then set a
macro as appropriate.  Having to use predefined macros based on the
system and compiler used is not very portable regardless and the purpose
of CMake appears to be cross platform, compiler and even makefile vendor
format so I would suggest the OP go back to cmake.org to request a
change so that true cross platform compatibility can be achieved based
on the function of the compiler instead of filtering on the predefined
macros.

-- 
Earnie
-- http://www.for-my-kids.com

On 28 February 2011 15:02, Earnie wrote:
> Keith Marshall wrote:
>> On 28 February 2011 12:22, Michael T. wrote:
>>> So you're saying that mingw gcc defines both _WIN32 and __GNUC__
>>
>> Yes.  FWIW:
>>
>>   $ gcc -E -dM nul.c
>
> It shouldn't matter that _WIN32 or __GNUC__ is defined.  The autoconf
> 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.

-- 
Regards,
Keith.

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 since SYMLINK
doesn't work on Windows and native msvcrt.dll doesn't understand
shortcuts.  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.

-- 
Earnie
-- http://www.for-my-kids.com

Keith Marshall wrote:
> On 28 February 2011 12:22, Michael T. wrote:
>> So you're saying that mingw gcc defines both _WIN32 and __GNUC__
> 
> Yes.  FWIW:
> 
>   $ gcc -E -dM nul.c

It shouldn't matter that _WIN32 or __GNUC__ is defined.  The autoconf
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.


-- 
Earnie
-- http://www.for-my-kids.com

Mcgroder, James wrote:
> Is the www.mingw.org site down? 
> I've been getting connection refused when I try to access...

The server's been hacked.  There is a ticket opened with NetworkRedux.

-- 
Earnie
-- http://www.for-my-kids.com

On Mon, 28 Feb 2011 12:39:58 +0000, Keith Marshall wrote:
>
> On 28 February 2011 12:13, Michael T.  wrote:
> > On 28 February 2011 11:22, John Brown wrote:
> >> What indentation? I don't see any indentation.
> >
> > It was in the original post but got lost in the email formatting.
>
> It is also clearly visible in the archive copy here:
> http://thread.gmane.org/gmane.comp.gnu.mingw.user/35619/focus=35690
>
> The reformatting is clearly a problem in *your* mail client.
>

Indeed. Hotmail does strip away white space (even new lines) sometimes,
as well as anything enclosed in angle brackets, such as #include file
names. Apparently XML is evil.

Regards,
Alias John Brown.
 		 	   		  

On 2011-02-28 11:22Z, John Brown wrote:
> On Mon, 28 Feb 2011 10:39:20 +0000, Keith Marshall wrote:
>> On 28 February 2011 10:12, Michael T. wrote:
[snip header snippet]
>> Well, that doesn't look right. Besides the possibly flawed logic, the
>> indentation of the # symbols introducing the preprocessor directives is
>> rank bad style; they should all be in column 1. GCC will tolerate this,
>> but some other compilers may not be so forgiving.

As a matter of style, I keep the '#' in the first column. Yet the example
in K&R2, page 91, 4.11.3, indents '#define' as in the [snipped] header:

#if SYSTEM == SYSV
    #define HDR "sysv.h"

and C99 [6.10/2] and C++2003 [16/1] require only that '#'
  "follows white space containing at least one new-line character"

Some ancient preprocessors choked on this:
  http://stackoverflow.com/questions/1854550/c-macro-define-indentation
but they're not C89 compliant.

> What indentation? I don't see any indentation.

Then your email program suppressed it, but it's visible here:
  http://article.gmane.org/gmane.comp.gnu.mingw.user/35690

On 28 February 2011 12:22, Michael T. wrote:
> The library was compiled with "Mingw makefiles" option for the cmake
> program. So I guess it should have been taken care of.

I don't know enough about cmake, to say whether it should have, or not.
However, it does look like something that the OpenCV folks themselves
may have explicitly specified incorrectly.

> So you're saying that mingw gcc defines both _WIN32 and __GNUC__

Yes.  FWIW:

  $ gcc -E -dM nul.c

will list all the #defines which are predefined by the compiler; (on
platforms other than Windows, you need to substitute the host specific
equal of nul.c, e.g. -xc /dev/null on *nix hosts).

> Yeah, that seems as a contradiction

Why?  The compiler *is* GNU-C, and the runtime platform *is* _WIN32;
there is no contradiction here.

> at the first glance and it seems the opencv developers didn't include
> this option in their logic.

That would be my guess.  The problem is not a contradiction in the
compiler, but rather that the OpenCV folks are predicating a choice on
the basis of a relationship between two logically unrelated concepts.

> So what is your advice? Change the header manually or turn off the
> warnings?

Fix it manually, in your own working copy of the header file, then offer
a patch to the OpenCV folks?

> I tried to post this on the opencv mailing list but it didn't work
> after even double trying (registration etc.)

Well, I can't help with that.  Keep trying, or follow whatever other bug
reporting guidelines they advertise on their web-site.

-- 
Regards,
Keith.

On 28 February 2011 12:13, Michael T. <my...@se...> wrote:
> On 28 February 2011 11:22, John Brown wrote:
>> What indentation? I don't see any indentation.
>
> It was in the original post but got lost in the email formatting.

It is also clearly visible in the archive copy here:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/35619/focus=35690

The reformatting is clearly a problem in *your* mail client.

-- 
Regards,
Keith.

> >
> > #ifndef CV_INLINE
> > #if defined __cplusplus
> >    #define CV_INLINE inline
> > #elif (defined WIN32 || defined _WIN32 || defined WINCE) \
> >    && !defined __GNUC__
> >    #define CV_INLINE __inline
> > #else
> >    #define CV_INLINE static
> > #endif
> > #endif /* CV_INLINE */
> 
> Well, that doesn't look right.  Besides the possibly flawed logic, the
> indentation of the # symbols introducing the preprocessor directives is
> rank bad style; they should all be in column 1.  GCC will tolerate this,
> but some other compilers may not be so forgiving.
> 
> > I do not know whether id ends up being static
> 
> For a C compilation, yes, it does; for C++ it will be "inline".
> 
> > or it meets the conditions of the #elif branch.
> 
> Nope.  __GNUC__ *is* defined, so it cannot, irrespective of _WIN32 also
> being defined.
> 

The library was compiled with "Mingw makefiles" option for the cmake program.
So I guess it should have been taken care of. 
So you're saying that mingw gcc defines both _WIN32 and __GNUC__
Yeah, that seems as a contradiction at the first glance and it seems the opencv developers didn't include this option in their logic.

So what is your advice? Change the header manually or turn off the warnings?
I tried to post this on the opencv mailing list but it didn't work after even double trying (registration etc.)


> Regards,
> Keith.
> 
> ------------------------------------------------------------------------------
> 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
> Min...@li...
> 
> 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
> Also: mailto:min...@li...?subject=unsubscribe
> 
> 
> 

> > > #ifndef CV_INLINE
> > > #if defined __cplusplus
> > > #define CV_INLINE inline
> > > #elif (defined WIN32 || defined _WIN32 || defined WINCE) \
> > > && !defined __GNUC__
> > > #define CV_INLINE __inline
> > > #else
> > > #define CV_INLINE static
> > > #endif
> > > #endif /* CV_INLINE */
> >
> > Well, that doesn't look right. Besides the possibly flawed logic, the
> > indentation of the # symbols introducing the preprocessor directives is
> > rank bad style; they should all be in column 1. GCC will tolerate this,
> > but some other compilers may not be so forgiving.
> >
> 
> 
> What indentation? I don't see any indentation.

It was in the original post but got lost in the email formatting.

> Regards,
> Alias John Brown.
>  		 	   		  
> ------------------------------------------------------------------------------
> 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
> Min...@li...
> 
> 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
> Also: mailto:min...@li...?subject=unsubscribe
> 
> 
> 

On Mon, 28 Feb 2011 10:39:20 +0000, Keith Marshall wrote:
>
> On 28 February 2011 10:12, Michael T. wrote:
> >> [...]
> >
> > In the beginning of the header file there is this "if - tree"
> >
> > #ifndef CV_INLINE
> > #if defined __cplusplus
> > #define CV_INLINE inline
> > #elif (defined WIN32 || defined _WIN32 || defined WINCE) \
> > && !defined __GNUC__
> > #define CV_INLINE __inline
> > #else
> > #define CV_INLINE static
> > #endif
> > #endif /* CV_INLINE */
>
> Well, that doesn't look right. Besides the possibly flawed logic, the
> indentation of the # symbols introducing the preprocessor directives is
> rank bad style; they should all be in column 1. GCC will tolerate this,
> but some other compilers may not be so forgiving.
>


What indentation? I don't see any indentation.

Regards,
Alias John Brown.
 		 	   		  

On 28 February 2011 10:12, Michael T. wrote:
>> [...]
>> > types_c.h:325: warning: 'cvCeil' defined but not used
>> [...]
>> > CV_INLINE int cvCeil( double value )
>> > { [...]
>>
>> Is CV_INLINE a macro that makes the function 'static'?
>
> In the beginning of the header file there is this "if - tree"
>
> #ifndef CV_INLINE
> #if defined __cplusplus
>    #define CV_INLINE inline
> #elif (defined WIN32 || defined _WIN32 || defined WINCE) \
>    && !defined __GNUC__
>    #define CV_INLINE __inline
> #else
>    #define CV_INLINE static
> #endif
> #endif /* CV_INLINE */

Well, that doesn't look right.  Besides the possibly flawed logic, the
indentation of the # symbols introducing the preprocessor directives is
rank bad style; they should all be in column 1.  GCC will tolerate this,
but some other compilers may not be so forgiving.

> I do not know whether id ends up being static

For a C compilation, yes, it does; for C++ it will be "inline".

> or it meets the conditions of the #elif branch.

Nope.  __GNUC__ *is* defined, so it cannot, irrespective of _WIN32 also
being defined.

-- 
Regards,
Keith.

>   $ gcc -DCV_INLINE="static" -Wall unused.c
>   unused.c: In function 'main':
>   unused.c:13:7: warning: unused variable 'i'
>   unused.c: At top level:
>   unused.c:5:15: warning: 'cvCeil' defined but not used
> 
> Notice that, in all cases, we see the warning for the unused variable in
> the main() function, but it is only in the last case, where CV_INLINE is
> defined *exactly* as 'static', (but *not* inline), that we see a warning
> relating to the unused function.

Thank you for your sample effort.
So the problem is probably in the macro being defined as static.
However, this is an official OpenCV (latest release) header compiled with cmake for the MinGW platform.

It probably ends up being static due to this if tree:

#ifndef CV_INLINE
#if defined __cplusplus
    #define CV_INLINE inline
#elif (defined WIN32 || defined _WIN32 || defined WINCE) && !defined __GNUC__
    #define CV_INLINE __inline
#else
    #define CV_INLINE static
#endif
#endif /* CV_INLINE */

And perhaps it should've ended being __inline.
But because mingw gcc compiler defines the __GNUC__ id doesn't?

Michael

> -- 
> Regards,
> Keith.
> 
> ------------------------------------------------------------------------------
> 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
> Min...@li...
> 
> 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
> Also: mailto:min...@li...?subject=unsubscribe
> 
> 
> 

> On 2011-02-25 11:15Z, Michael T. wrote:
> [...]
> > types_c.h:325: warning: 'cvCeil' defined but not used
> [...]
> > CV_INLINE int cvCeil( double value )
> > { [...]
> 
> Is CV_INLINE a macro that makes the function 'static'?

In the beginning of the header file there is this "if - tree"

#ifndef CV_INLINE
#if defined __cplusplus
    #define CV_INLINE inline
#elif (defined WIN32 || defined _WIN32 || defined WINCE) && !defined __GNUC__
    #define CV_INLINE __inline
#else
    #define CV_INLINE static
#endif
#endif /* CV_INLINE */

I do not know whether id ends up being static or it meets the conditions of the #elif branch. 

> > If I change the -Wall gcc argument to -W I don't get these warnings anymore.
> 
> '-Wall' and '-W' enable different sets of warnings--see:
>   http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
 But it's
> better to fix the problem, which I suppose is that a
> static function is defined in a header.

I also prefer fixing the problem, however the header is not a header that I have written.
It is part of the official latest release of the OpenCV library ( http://opencv.willowgarage.com/wiki/ )
 
> ------------------------------------------------------------------------------
> 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
> Min...@li...
> 
> 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
> Also: mailto:min...@li...?subject=unsubscribe
> 
> 
> 

> 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?

> 
> --
> 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
> Min...@li...
> 
> 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
> Also: mailto:min...@li...?subject=unsubscribe
> 
> 
> 

On 2/27/2011 10:45 PM, LRN wrote:
> Here ( http://lrn.no-ip.info/other/mingw/experimental-msys-perl/ ) are 
> my buildscript (with patches) and logs of the build (also, diffs between 
> initial unpatched testsuite output and the output of two patched 
> versions of it). This ML only allows attachments up to 140Kb, so you'd 
> have to download the files from my webserver.

OK, I'll take a look -- but I'm going to be busy for a few days so it'll
probably be Thu at the earliest...

--
Chuck

On 27.02.2011 22:02, Charles Wilson wrote:
> On 2/27/2011 9:16 AM, LRN wrote:
>> On 27.02.2011 6:57, LRN wrote:
>>> Actually, i'm trying to build perl 5.12.3 at the moment. I'll give
>>> your patch a try if that fails.
>> 5.12.3 builds! \o/
>> Testsuite is still unpatched, and i'm currently fixing the
>> installation/packaging procedure (i think it's worth a try to attempt to
>> use DESTDIR once again), but 5.12.3 builds without triggering
>> sync_with_child bug.
> If you get anything close to decent testsuite performance, I'll look
> into adopting some of the current cygwin patches/packaging in order to
> bundle some extensions (e.g. so that end users can, at least, then use
> CPAN for additional customizations).  Of course, cygwin perl is still at
> 5.10.3...
Here ( http://lrn.no-ip.info/other/mingw/experimental-msys-perl/ ) are 
my buildscript (with patches) and logs of the build (also, diffs between 
initial unpatched testsuite output and the output of two patched 
versions of it). This ML only allows attachments up to 140Kb, so you'd 
have to download the files from my webserver.
> 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.
Most certainly. I hope that rebasing perl after building it will prevent 
the testsuite from failing so much.

On 28.02.2011 2:31, Charles Wilson wrote:
> On 2/27/2011 5:21 PM, Keith Marshall wrote:
>> I find MSYS to be slightly faster than Cygwin, but it's still slow,
>> which is why I prefer to use a cross-compiler hosted on GNU/Linux; it's
>> an order of magnitude faster.
> 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...
>
> --
> Chuck
>
In that case you can implement something like MinWG (Minimalist Windows 
for GNU) and connect its Windows and *nix parts (one running natively, 
another - in VM) with sockets. If you handle the shared filesystem and 
I/O redirection correctly, you'd be able to run PE binaries on Windows, 
while everything else will remain in the VM.


...and no, i haven't been smoking anything...

On 2011-02-27 23:18Z, Chris Wilson wrote:
> On Sun, 27 Feb 2011, Keith Marshall wrote:
>> On 27/02/11 21:25, Chris Wilson wrote:
[...]
>>> Is there any point in trying to port the more common utilities away 
>>> from the MSYS DLL to native implementations? E.g. I can imagine that 
>>> using native bash, gcc, rm, etc. might be much faster. Does that make 
>>> sense?  Would it be difficult?  Perhaps the less commonly-used 
>>> utilities could remain under MSYS to ease the porting effort?

I looked into that a few years ago, and it seemed too difficult for me.

Besides, MSYS needs versions that recognize the MSYS filesystem so that
they can interpret commands like
  rm ~/foo.bar
so I suppose they have to be linked to the MSYS dll. If a particular
utility is especially slow, and you can identify an optimization like
replacing fork() and exec() with spawn() and push that change upstream,
then everyone would benefit.

>> 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?

Using a mingw.org version of gcc-3.4.5:

$cygcheck /MinGW_/bin/gcc
C:\opt\lmi\MinGW-20090203\bin\gcc.exe
  C:\WINDOWS\system32\KERNEL32.dll
    C:\WINDOWS\system32\ntdll.dll
  C:\WINDOWS\system32\msvcrt.dll

I don't know exactly how it invokes cpp, but I doubt it calls fork().

>> Many of the other tools are already available, as native Win32 
>> applications, from the GnuWin32 project; I've tried some of them, but 
>> I've always had better success using the MSYS variants.  You are welcome 
>> to try them; YMMV.  One stumbling block: last time I looked, I don't 
>> think they offered a Unixy shell; rather a show stopper, if you want to 
>> run a Bourne shell configure script.
> 
> Yes, I gather that bash doesn't run natively, but zsh apparently does, and 
> it might be "close enough" (I've heard a lot of people recommending zsh).

I used to use Amol Deshpande's old native port of zsh, but IIRC it was
zsh-3.0.5, which is outmoded--e.g., it doesn't provide printf(1). It
lives on, unmaintained, in this 2003 file:
  http://unxutils.sourceforge.net/zsh.zip
which IIRC is zsh-3.0.8: not much more modern. It's "resurrected" here:
  http://zsh-nt.sourceforge.net/
but that's still 3.0.8, a 2000-05-16 release. Unless it's actively
maintained, you're up a creek when you see "fork failed". I dropped it
years ago in favor of MSYS and Cygwin for reliability reasons.

On 2/27/2011 5:21 PM, Keith Marshall wrote:
> I find MSYS to be slightly faster than Cygwin, but it's still slow,
> which is why I prefer to use a cross-compiler hosted on GNU/Linux; it's
> an order of magnitude faster.

In general, MSYS should be faster than Cygwin -- because (a) it doesn't
do as much access checking, and (b) all the new posix support features
that have been added to cygwin over the last seven years, such as
i18n/widechar support, impose a runtime cost.

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...

--
Chuck

Hi Keith and all,

On Sun, 27 Feb 2011, Keith Marshall wrote:
> On 27/02/11 21:25, Chris Wilson wrote:
>> I've been thinking about using MSYS, but my initial experiments told
>> me that it doesn't provide nearly as much drop-in compatibility for
>> configure scripts as Cygwin does;
>
> That's not been my experience.  Any GCS conforming configure script
> should run equally well under MSYS and Cygwin sh.exe; perhaps if you
> need an esoteric tool, Cygwin is more likely to provide it.

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) :)

> I find MSYS to be slightly faster than Cygwin, but it's still slow, 
> which is why I prefer to use a cross-compiler hosted on GNU/Linux; it's 
> an order of magnitude faster.

I agree, but when it comes to testing, Wine doesn't cut it; and this 
project has several configure tests that rely on being able to execute 
programs, not just compile them, which also makes cross-compiling more 
difficult. Finally there are no RPMs for MinGW packages for CentOS, which 
is one of my main development platforms. (They now exist for Fedora 8, 
which I guess might help if I had time to recompile gcc, g++, etc.)

>> Is there any point in trying to port the more common utilities away 
>> from the MSYS DLL to native implementations? E.g. I can imagine that 
>> using native bash, gcc, rm, etc. might be much faster. Does that make 
>> sense?  Would it be difficult?  Perhaps the less commonly-used 
>> utilities could remain under MSYS to ease the porting effort?
>
> 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.

> Many of the other tools are already available, as native Win32 
> applications, from the GnuWin32 project; I've tried some of them, but 
> I've always had better success using the MSYS variants.  You are welcome 
> to try them; YMMV.  One stumbling block: last time I looked, I don't 
> think they offered a Unixy shell; rather a show stopper, if you want to 
> run a Bourne shell configure script.

Yes, I gather that bash doesn't run natively, but zsh apparently does, and 
it might be "close enough" (I've heard a lot of people recommending zsh).

As far as the other tools go, I suspect that they don't do path 
translation in the same way as MSYS does, and this might cause problems 
for configure scripts.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <chr...@qw...> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |

On 27/02/11 21:25, Chris Wilson wrote:
> I've been thinking about using MSYS, but my initial experiments told
> me that it doesn't provide nearly as much drop-in compatibility for
> configure scripts as Cygwin does;

That's not been my experience.  Any GCS conforming configure script
should run equally well under MSYS and Cygwin sh.exe; perhaps if you
need an esoteric tool, Cygwin is more likely to provide it.

> and I suspected it would be just as slow because MSYS components run
> under the MSYS dll (an old fork of the Cygwin DLL) in any case.

I find MSYS to be slightly faster than Cygwin, but it's still slow,
which is why I prefer to use a cross-compiler hosted on GNU/Linux; it's
an order of magnitude faster.

> Is there any point in trying to port the more common utilities away
> from the MSYS DLL to native implementations? E.g. I can imagine that
> using native bash, gcc, rm, etc. might be much faster. Does that make
> sense?  Would it be difficult?  Perhaps the less commonly-used
> utilities could remain under MSYS to ease the porting effort?

Well, our GCC and binutils tool chain is already 100% native.  Many
of the other tools are already available, as native Win32 applications,
from the GnuWin32 project; I've tried some of them, but I've always had
better success using the MSYS variants.  You are welcome to try them;
YMMV.  One stumbling block: last time I looked, I don't think they
offered a Unixy shell; rather a show stopper, if you want to run
a Bourne shell configure script.

-- 
Regards,
Keith.