Re: Using Perl's cc

[Eli Zaretskii]

> Date: Sat, 4 Jul 2015 13:10:07 +0100
> From: Gavin Smith <address@hidden>
> Cc: address@hidden
> 
> On 4 July 2015 at 09:03, Eli Zaretskii <address@hidden> wrote:
> >> Why does the MSYS installation of Perl have to be used at all?
> >
> > Because when a Perl script invokes /usr/bin/program, or references
> > /dev/tty or /dev/stdout, a native Windows build of Perl will not be
> > able to DTRT.  And because shell scripts expect Perl to produce
> > Unix-style EOLs in their output.  And for umpteen other subtleties
> > that can make running a build a nightmare on Windows.  The MSYS
> > toolchain makes all that magically work, which is its single most
> > important raison d'être.  Its only problem is that its development
> > stagnated, so even its Perl is not 100% up to the texi2any job (it
> > spits out 2 non-fatal warnings while processing the Emacs Lisp
> > Reference manual).
> 
> If the development headers are available for MSYS Perl along with the
> compiler used to compile it, then that compiler could be used to build
> the extension. From what I hear from you, this is very unlikely
> though.

Extremely unlikely.  E.g., I don't have the MSYS development tools
installed, because I never need to develop MSYS tools.  I just use
them.

> If MSYS Perl is not used when texi2any is run, then these problems
> like "/dev/tty" and umpteen other things that I don't know about
> wouldn't be taken care of, unless Strawberry Perl etc. can take care
> of them.

They could, potentially.  Fortunately, texi2any doesn't have such
non-portable stuff, because it works with native Windows builds of
Perl.

The problem that requires using an MSYS Perl are in random Perl
scripts used by the build processes in some packages.  I don't
remember which package was the first to exhibit problems with the
native Windows Perl: that was long ago, and once I installed the MSYS
Perl, the problems went away and never came back.

> Regarding this:
> >And because shell scripts expect Perl to produce Unix-style EOLs in their 
> >output.
> 
> this would only be a problem if shell scripts were processing the
> output of texi2any, which would be mostly error messages. MSYS Perl
> could still be used in most other cases, just not when texi2any is
> run.

Once again, I was not talking about texi2any.  Sorry for not making
that clear.

> Suppose you have a C program that does #include <stdio.h> and calls
> "fprintf(stderr, "This is a message\n")". It's compiling against libc,
> suppose a shared library, "libc.so.16". But in the next version of the
> library, the loadable object for which being "libc.so.17", there is an
> incompatible change, and stderr is no longer defined as "2", but now
> defined as "99". Anyone wanting to use this C program on a system
> where stderr has this new value would have to compile it against a new
> "stdio.h". If you use a different compiler, things could go wrong as
> well, if it uses an exotic calling convention, so that, e.g., some of
> the processor registers used by our program don't get saved when
> "fprintf" is called into.

Yes, I understand all that.

> This example has obvious flaws, but hopefully they won't get in the
> way. Like the C program in our example, we're including development
> headers, like "XSUB.h". In order to be compatible with the Perl
> instance, they have to match the Perl executable being used when the
> code in the extension module is run.

The problem with this analogy is that MS-Windows does much better wrt
backward compatibility than a typical Unix or GNU system.  The default
shared library that implements the C runtime, as distributed with all
Windows versions since 9x till these days, has the same name and
presents the same backward-compatible ABI.  Newer versions of the C
libraries are shipped under different names, and programs need to be
linked against them to use them at run time.

So a program I built 20 years ago will still run on today's latest
Windows box without any problems.  I actually have a few of such
programs on my box.

No other solution would have worked well, because Windows systems
don't come with a compiler installed, and most users won't know how to
rebuild a program, nor have its sources, anyway.

So Windows users are used to having binaries that "just work" out of
the box, without rebuilding.  Asking them to upgrade unrelated
packages for that, or even providing a different version of Perl as
part of the package, will be frowned upon.  It's highly irregular.