RE: mingw32 - noncygwin32 gcc - libwinserve.a

RE: mingw32 - noncygwin32 gcc - libwinserve.a

[Colin Peters]

Jan-Jaap van der Heijden[SMTP:janjaap@Wit381304.student.utwente.nl] wrote:
>On Wed, 15 Oct 1997, Pedro A. Aranda Gutiirrez wrote:
>
>> Earnie Boyd wrote:
>> > I have found a bug in the mingw32 version of gcc though:
>> > If you have spaces in a -Dmacro='"this that something"' gcc comes back
[snip: an error]
>> 
>> I would say that it is ***AND*** it isn't a bug in gcc. It's the
>> behaviour of manyGNU tools once recompiled to use CRTDLL.DLL <snif>. It
>> has something to do
>> with the way we pass arguments to the spawn...() functions. As far as I
[snip]
>
>This is supposed to be fixed in the test "prerelease" which is in
> ftp://agnes.dida.physik.uni-essen.de/home/janjaap/private/mingw32/
>
>To quote the source:
>
>/* This is a kludge to get around the Microsoft C spawn functions'
>   propensity to remove the outermost set of double quotes from all
>   arguments.  */

It's only partially spawn's fault. Spawn doesn't do anything to
quotes in args, or slashes, backslashes, or anything else.
Unfortunately what we have here (if I am correct) is a basic
limitation of the OS. Arguments are not passed between processes
as a block of null-terminated strings, but as a single command
line string (curse the programmer who made this coding
decision). Spawnv can do nothing but attempt to create a
reasonable command line from the argv block, and what it does is
concatinate all the members of the block together, with a single
space between each.

Then the mingw32 startup code calls _GetMainArgs, which is
implemented in crtdll, to break up the command line into tokens
and put them in an __argv block. Of course, if any of the args
passed to spawnv contained spaces then the tokenization will
not be the same.

In order to allow args with spaces _GetMainArgs allows args to
be quoted, and quotes to be escaped with backslashes, and
backslashes in front of quotes to be escaped with backslashes.
To get exactly the same thing that you mean to pass with spawn
in the argv array of a mingw32 program (or probably any MS
program-- confirmations for VC++ behavior anyone?) you have to
follow these rules (I think):

 - Double all backslashes preceeding a quote (including sets
   of multiple backslashes e.g. \\" -> \\\\", if you don't do
   this \\" -> \\\" and after the next step \\\\", and that
   ends up as \\ in the called program, with the quote dropped).
   Do not double backslashes that are not in front of a quote.
 - Put a backslash in front of all quotes within an arg.
 - Put quotes around all args containing whitespace.

This is ugly ugly ugly... and it's also one of the things I
wish MS would break compatibility to fix. The shell or calling
process should tokenize the args, not the new process, and
pass them as a block, like UNIX does (if I understand correctly).

Still, I am not yet decided whether, in the context of mingw32,
this is a problem that should be fixed at all. Basically my
argument is:

 1) Most of the time this does not cause problems, and many of
    those problems can be solved by properly quoting args on
    the command line.

 2) Mingw32 makes a best effort to be compatible, but it is,
    essentially, a way of morphing GCC into a Win32 complier.
    Offering total UNIX compatibility is much better done with
    a completely independent C run time-- Mingw32 cannot hope
    to implement fork, signals, etc. in a UNIX compatible way
    without completely abandoning any pretense of "minimalism".

It's possible that spawn wrappers, like the dirent
implementation, will be small and useful enough to warrent
their inclusion. I would be more convinced if it was more than
just an unusual argument to gcc that was breaking.

I don't think it is a good idea to patch gcc to fix this
problem. If we are going to fix it, instead of working around
it on the command line itself, then we should do it by fixing
the library underneath the spawn calls. Patching gcc for this
failure in Win32 will only incur the ire of anti-win32 elements
within the GNU community, as well as being inefficient.

Of course, this isn't "my" code, and I have no real authority,
but I just wanted to put some of the issues I see on the table.

Just fishing for opinions,
Colin.

PS. I'm willing to make some work towards implementing those
    wrappers, although I can't say how quickly it will be done.

PPS. Jan-Jaap: I'd like to pass you a version of mingw32 0.1.5
     to do a once-over before I release it, if you have time.
     That would be some time next week I hope.

PPPS. Direct flames straight to me and keep the list free of
      napalm. :)

-- Colin Peters - Saga Univ. Dept. of Information Science
-- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: mingw32 - noncygwin32 gcc - libwinserve.a

[Colin Peters]

Earnie Boyd[SMTP:earnie_boyd@hotmail.com] wrote:
>I've also noted that the mingw32 version of gcc (I say that it is gcc 
>because it doesn't matter which shell is used) removes all quotes from 
>the command line.  E.G.: The makefile from bash-2.01 has a command line 
>definition of -DPROGRAM='"bash"'; when the compiler sees this it is 
>trying to resolve the reference to bash as a variable not as a literal.

With the version of gcc I am using (the mingw32 native version linked
to from my homepage) this can be solved by doing the following, extremely
ugly, escaping:

 gcc junk.c "-DX=\"\\\"the X string\\\"\""

gcc gets -DX="\"the X string\"" as a single argument, which is then passed
on to cpp, which does similar stripping and escaping to get -DX="the X string"
as a single argument (gcc junk.c -DX="\"\\\"the X string\\\"\"" should work
too, as should gcc junk.c "\"-DX=\\\"the X string\\\"\""). My source file:

#define	Y	"the Y string"

char szX = X;
char szY = Y;

Gets expanded (-E output) as:

# 1 "junk.c"



char szX = "the X string" ;
char szY = "the Y string" ;

Which sounds like what you want.

This is, of course, with both gcc and cpp compiled using mingw32.

There are options in Mingw32 (at least since 0.1.4, if not earlier)
for turning off "globbing" of the command line from inside a program,
but they do not seem to turn off this escaping and quoting. However,
I don't think it is done by command.com, because it also happens when
a program is invoked through spawn* (I think), and the Win32 API
GetCommandLine returns the command line with the quotes intact in any
case. (If you really needed complete control over the command line
under Mingw32 GetCommandLine plus your own processing is probably the
best you can do.)

Anyway, the short answer to your question of a few days ago about
escaping quotes and such is: yes. There are ways of escaping things
so they get where they need to go in the right form, but you have
to know how many times the escaping is going to be done to get it
right.

How this all plays out when bash or another shell is in the mix trying
to do escaping and quoting as well has not been investigated (by me).

Hope this helps a bit.

Colin.

-- Colin Peters - Saga Univ. Dept. of Information Science
-- colin@bird.fu.is.saga-u.ac.jp - finger for PGP public key
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html
-- http://www.geocities.com/Tokyo/Towers/6162/

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: mingw32 - noncygwin32 gcc - libwinserve.a

[Earnie Boyd]

>Date: Wed, 15 Oct 1997 07:44:51 +0100
>From: "Pedro A. Aranda Guti\irrez" <paag@tid.es>
>To: Earnie Boyd <earnie_boyd@hotmail.com>
>Cc: colin@bird.fu.is.saga-u.ac.jp, J.J.vanderHeijden@student.utwente.nl
>Subject: Re: mingw32 - noncygwin32 gcc - libwinserve.a
>
---snip---
>
>Which bash are you using. The CYGWIN-bash, an MSDOS bash or a MINGW32
>versionof bash. If it is the latter, I'd like to know how you got it
>compiled. It's been my main headache
>for the last couple of months. I do refuse to install the cygwin.dll
>monster in my PC.
>

As for BASH I'm currently using bash-2.01 that I compiled with the 
out-of-the-box version of cygwin.dll.  As for compilation I chose the 
package rman-3.0.3a12 as it was small (1 module) in size.  To get it to 
compile I had to remove the -D options from gcc and insert them into a 
header file that I then included in the source.  I then issued the 
necessary build command from MSDOShell.

I've also noted that the mingw32 version of gcc (I say that it is gcc 
because it doesn't matter which shell is used) removes all quotes from 
the command line.  E.G.: The makefile from bash-2.01 has a command line 
definition of -DPROGRAM='"bash"'; when the compiler sees this it is 
trying to resolve the reference to bash as a variable not as a literal.

As for the cygwin.dll, Cygnus Support and all involved have made a great 
contribution to the process of making programs portable.  However, if 
there license prevents anyone from using it for whatever purpose 
desired, even compilers, I question whether I can totally support it.  
However, I have been given the use of it and will use it and have 
enjoyed using it and will help others use it.

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: mingw32 - noncygwin32 gcc - libwinserve.a

[Earnie Boyd]

>From: Colin Peters <colin@bird.fu.is.saga-u.ac.jp>
>To: "'Earnie Boyd'" <earnie_boyd@hotmail.com>
>Subject: RE: mingw32 - noncygwin32 gcc - libwinserve.a
>Date: Tue, 14 Oct 1997 13:23:59 +0900
>
>Earnie Boyd[SMTP:earnie_boyd@hotmail.com] wrote:
>>I have ported rman-3.0.3a12 using cygwin32 without much ado.  I have 
>>ported mingw32 and gcc without the cygwin layer and "for grins" tried 
to 
>>port rman-3.0.3a12 vanilla WNT3.51.  I used the object file rman.o 
from 
>>the cygwin32 build and try to create rman.exe.  I have the paths set 
so 
>>that none of the gnuwin32 paths are searched.
>>
>>I resolved undefined references by adding the following libraries:
>>
>>   -lg -liberty -lwinserve
>>
>>   libg.a took care of a lot of _impure_ptr and __swbuf references.
>>
>>   libiberty.a took care of the __progname reference introduced by 
>>libg.a.
>>
>>   libwinserve.a took care of the _sbrk reference.
>>
>>Now I have an executable without the cygwin.dll reference.  However, 
>>when I execute I get an this error "The dynamic link library 
>>winserve.dll could not be found in the specified path...".
>
>It might be more straightforward to compile the rman.o object file
>in a mingw32 environment, though you may have to work around missing
>system calls (if any) in the source. I'm not sure that the approach
>you are taking will work.
>

---snip---


Thanks for your reply Colin.  I have recompiled with the mingw32 
environment and the program works fine.

I had previously copied all of the include files from cygwin to a 
directory I called "cinclude" and added it to the gcc search path.
I had to, however, mutz with combining the sys/types.h file from cygwin.  
This led to also futzing with time.h.  But I finally got the things 
compiled and linked and working.

I have found a bug in the mingw32 version of gcc though:
If you have spaces in a -Dmacro='"this that something"' gcc comes back 
with:

gcc: that: No such file or directory
gcc: something": Invalid argument

this happens with both MSDOS and BASH so it is not a shell thing.  The 
work around was to do a #define in the program.


??TOTALLY UNRELATED?? Is there an escape character such as the \ in BASH 
for MSDOS?  I ask this because the Makefile script has "%s(%s)" as part 
of a macro definition and in MSDOS you end up with s) as it tries to 
resolve %s(% as an environment variable.

Thanks again,

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

mingw32 - noncygwin32 gcc - libwinserve.a

[Earnie Boyd]

Colin,

I have ported rman-3.0.3a12 using cygwin32 without much ado.  I have 
ported mingw32 and gcc without the cygwin layer and "for grins" tried to 
port rman-3.0.3a12 vanilla WNT3.51.  I used the object file rman.o from 
the cygwin32 build and try to create rman.exe.  I have the paths set so 
that none of the gnuwin32 paths are searched.

I resolved undefined references by adding the following libraries:

   -lg -liberty -lwinserve

   libg.a took care of a lot of _impure_ptr and __swbuf references.

   libiberty.a took care of the __progname reference introduced by 
libg.a.

   libwinserve.a took care of the _sbrk reference.

Now I have an executable without the cygwin.dll reference.  However, 
when I execute I get an this error "The dynamic link library 
winserve.dll could not be found in the specified path...".

The final command line to build rman.exe is "gcc -O2 -finline-functions 
-o rman.exe rman.o -liberty -lg -lwinserve -v".

The -v returns:

 ld -o rman.exe C:\users\bcoeeb0\mingw32\lib\crt0.o 
-LC:\users\bcoeeb0\mingw32\lib\gcc-lib\i386-mingw32\2.7.2.1 
-LC:\users\bcoeeb0\mingw32\lib\gcc-lib -LC:\users\bcoeeb0\mingw32\lib 
-LC:\users\bcoeeb0\mingw32\win32\lib -L. rman.o -liberty -lg -lwinserve 
-lmingw32 -lgcc -lmoldname -lcrtdll -lkernel32 -lmingw32 -lgcc 
-lmoldname -lcrtdll



What do I need to do that I'm not doing?  Is what I am trying to do an 
impossibility?

Thanks,
-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".