Re: Problems with $(shell xxx) using uWin

[James Kanze]

Eli Zaretskii wrote:
>> Date: Sat, 03 Jun 2006 23:06:03 +0200
>> From: James Kanze <address@hidden>
>> Cc: address@hidden

>>  >   http://gnuwin32.sourceforge.net/

>> Thanks.  But make doesn't seem to be there.

> You already have Make, the one you compiled with MSVC.

But it doesn't work.  I was hoping for a pre-compiled make which
did work.  (I will look into it as an alternative to UWin and
CygWin.)

>> Nor bash, for that matter.  Both UWin and CygWin (and MKS, if
>> you can afford it) provide fully integrated, complete
>> environments.  My make files (and my way of working) depend
>> on a full Unix environment, including a Unix like shell.

> There are some native ports of a Unixy shell out there.  I use
> a ported zsh, and it works well enough for running Makefiles
> and not-too-complex shell scripts.

As I think I mentionned, I aim for a low common denominator, so
that any Bourne-like shell should work.

>> (If make had been present, I would have downloaded their
>> version.  I'm still not really sure that the problem doesn't
>> come from something I did in building it.)

> I'm quite sure the problem is not in how you built Make.

I am too, now.  The problem seems to be in reading from the
pipe, when make spawns a child.

>> One of the requirements in moving the code to Windows is that
>> it must compile with Visual C++.  (On the other hand, MinGW
>> might be a good choice for compiling make.)

> I doubt that a MinGW build would change anything: it's a
> different compiler, but it compiles the same source code as
> MSVC (apart from insignificant syntax-related issues), and the
> produced binary uses the same runtime as the MinGW build.

> One thing to try is to change the optimization level.
> build_w32.bat supports a ``Debug'' build and a ``Release''
> build.  Whichever of them you produced, try the other one, and
> see if the problem goes away.

I'll give it a try.  I think I first tried with the release
build, but I'm no longer sure; since then, I know that I've only
been working with the debug build.

>> My real problem is simply: I have a significant body of code
>> developped under Unix (Solaris, mainly), with a build system
>> based on a fairly advanced use of GNU make.  I am trying to
>> port it to Windows, while doing the least amount of work
>> possible.

> We may have different goals here.  My goal is to try to fix
> bugs in the native Windows (MinGW and MSVC) builds of Make,
> while yours is to have your code build with a minimal effort.

Well, my real goal is to make my libraries available to Windows
programmers, with a minimum of effort for them.  If it means
that I have to do a little extra work up front, so be it.  If I
find that it is a bug, and I find a fix for it, for example, I
will make a pre-compiled binary with the patches available on my
site, so that other users don't have to worry about when they
finally get into the official source tree.

>>  > If it causes $(shell ls *.cc) to work, then the UWIN port of
>>  > shell is the primary suspect.

>> I still get the funny pop-up.

> That probably means Make crashes either on exit or when $shell
> returns.

Actually, I've found more or less where it crashes -- when it
calls close with a file descriptor of -1, because an earlier
system request failed.  I think I've got a simple work-around,
which I am going to test.  But now that I'm into the code, I'd
like to understand what is going on.  Which, in this case,
involves documenting myself about a number of calls to the
Windows API.

> Are you saying that Make generally works, except when you use
> $shell?  If so, then unless you can debug the problem on your
> machine, a workaround would be to refrain from using $shell.
> For example, $(shell pwd) can be replaced by $(CURDIR).

That's a solution I'm considering.  At present, most of the uses
of $(shell ...) are to get the name of the current directory
(which is used to derive the name of the component, which in
turn determines some other directory names, etc.).  There are
two other uses, however:

-- The first may not be important; I use $(shell) to execute a
   more or less complicated shell script to determine the
   version of the compiler, generating an error if the version
   isn't recent enough.  I really only introduced this because
   of particular conditions where I work.  If a user tries to
   do a complete build with a compiler which is too old, it
   will fail.

-- To manage different site information according to the
   machine make is running on.  This is, again, linked to the
   use of remote mounted files: in site.mk (a file included
   from all of the other makefiles), there is a line like:

       include $(root)/Site/site.$(strip $(shell uname -n)).mk

   This is important, it is in site.xxx.mk, for example, where
   I specify the command for a Posix conformant awk
   (/usr/xpg/awk under Solaris, awk --posix under Linux, etc.),
   as well as information concerning the configuration (in the
   form of three variables: comp, arch and syst, for the
   compile, system architecture and OS).

I can drop the first use if necessary; it's really not really
important.  But I do need something for the second -- if there's
another way to determine the name of the machine from inside
make, fine.

   [...]
>> On the other hand, while it would surprise me somewhat, I
>> suppose I could be the first to use $(shell...) in the UWin
>> environment (with a non-standard -- for Windows -- command
>> processor).

> You are definitely not the first; I do it as well, and many others
> too.  I just don't use UWIN.  (Looked at it, saw that it required a
> runtime DLL and came with a whole slew of UWIN-specific ports, and got
> turned off.  I don't like packages that ask you to marry them for
> life and that don't run natively, which means won't work well with
> native programs.  But that's me.)

Well, I don't think I looked that far.  I was using CygWin, had
a problem with it, and a collegue suggested UWin.  On the whole,
it seems to work better than CygWin.  Or did, until this
problem.

In the meantime, of course, I can affirm that the problem is
present without UWin.

   [...]
>>>>     /C/UWIN\usr\bin\pwd: line 4: uwin\usr\bin\pwd: not found

> Except that it fails to run pwd, probably because it cannot
> cope with mixed forward- and back-slashes in file names, or
> for some other reason.

For the moment, I've simplified the problem, by running in a
cmd.exe Window, with no UWin in the path, and using a command
which isn't built-in.  I still get the problem.

> So it looks like sub_proc.c works as intended in your case,
> and the reason for the crash is elsewhere, either in some
> other place in the code, or in the environment created by the
> UWIN port of the shell.

I've got it down to the Windows specific code in function.c.  In
particular, the pipe handling.  To go further, I'm first going
to read up on some of the Windows API; an fprintf(cerr)
immediately before a call to close works, the one immediately
after doesn't.  But how can a call to close possibly core dump?

The current situation is: 1) I will continue to try to figure
out what isn't working, if for no other reason than I want to
understand, 2) I will try to rewrite the makefiles to avoid
$(shell), and 3) I will look into the various other alternatives
to UWin which have been mentioned.  (But it all takes time I
would rather spend developing new code.)

--
James Kanze                                    address@hidden
Conseils en informatique orientée objet/
                 Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34