From stecmccarthy@hotpop.com

The following message from Configure doesn't seem to make sense​:

Checking compatibility between /bin/echo.exe and builtin echo (if any)...
/home/Stephen/perl-5.8.6/Configure​: /bin/echo.exe​: No such file or directory
They are not compatible! You are probably running ksh on a non-USG system.
I'll have to use /bin/echo.exe instead of the builtin, since Bourne shell
doesn't
have echo built in and we may have to run some Bourne shell scripts. That
means I'll have to use '\c' to suppress newlines now. Life is ridiculous.

Yes, it does seem ridiculous. My shell has a builtin echo, but I do not have
a function echo in the bin. Hence, there is no compatibily problem between
them. The logic breaks down when Configure decides to use echo.exe because I
don't have echo.exe. I mean, Configure decides to use echo.exe instead of
the builtin echo even if the reason they are different and therefore
incompatible is that there is no echo.exe available. Configure should check
to see they both exist before comparing them!

I am attempting to figure out how to tell Configure to use the builtin echo
from the command line.

I am using msys and there is a file echo in /bin that calls builtin echo,
perhaps this is confusing Configure. I will remove it... echo still works, I
will try running Configure again. That does not work. I want Configure to
use the builtin echo, but it does not recognize it. It says​:

I don't know where 'echo' is, and my life depends on it.
Go find a public domain implementation or fix your PATH setting!

I can't figure it out, but I know that the message that I do not have a
builtin echo is false.

Stephen

From @ysth

On Thu, Jan 27, 2005 at 05​:45​:04AM -0000, Stephen wrote​:

I am attempting to figure out how to tell Configure to use the builtin echo
from the command line.

Try -Decho=echo

The RT System itself - Status changed from 'new' to 'open'

From stecmccarthy@hotpop.com

Sorry, it does not work, I don't think there is a way, however, the message Configure displays saying there must not be a builtin echo when really there is no echo.exe should be changed. It is probably not a high priority, but Configure could use a little update. For instance, it includes sys/file.h instead of fcntl.h when sys/file.h in only a dummy that call fcntl.h anyway​:

<sys/file.h> defines the O_* constants...
and you have the 3 argument form of open().
Using <string.h> instead of <strings.h>.
<sys/file.h> found.
We'll be including <sys/file.h>.
<fcntl.h> found.
We don't need to include <fcntl.h> if we include <sys/file.h>.

----- Original Message -----
From​: "Yitzchak Scott-Thoennes via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Thursday, January 27, 2005 7​:25 AM
Subject​: Re​: [perl #33948] configure checking echo

On Thu, Jan 27, 2005 at 05​:45​:04AM -0000, Stephen wrote​:

I am attempting to figure out how to tell Configure to use the builtin echo
from the command line.

Try -Decho=echo

From @doughera88

On Thu, 27 Jan 2005, Stephen wrote​:

# New Ticket Created by "Stephen"
# Please include the string​: [perl #33948]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=33948 >

The following message from Configure doesn't seem to make sense​:

Checking compatibility between /bin/echo.exe and builtin echo (if any)...
/home/Stephen/perl-5.8.6/Configure​: /bin/echo.exe​: No such file or directory

This is a sign that Configure's gotten confused even earlier. Could you
please re-run Configure and look near the beginning where it says
something like

  Locating common programs...
  awk is in /usr/bin/awk.
  cat is in /usr/bin/cat.
  chmod is in /usr/bin/chmod.
  comm is in /usr/bin/comm.
  cp is in /usr/bin/cp.
  echo is in /usr/bin/echo.
  expr is in /usr/bin/expr.

What does it say for echo?

At this point, Configure thinks it has found a working 'echo' program;
later on, it doesn't go back and recheck that assumption. That's at the root
of the later confusion.

They are not compatible! You are probably running ksh on a non-USG system.
I'll have to use /bin/echo.exe instead of the builtin, since Bourne shell
doesn't
have echo built in and we may have to run some Bourne shell scripts. That
means I'll have to use '\c' to suppress newlines now. Life is ridiculous.

Yes, it does seem ridiculous. My shell has a builtin echo, but I do not have
a function echo in the bin. Hence, there is no compatibily problem between
them. The logic breaks down when Configure decides to use echo.exe because I
don't have echo.exe. I mean, Configure decides to use echo.exe instead of
the builtin echo even if the reason they are different and therefore
incompatible is that there is no echo.exe available. Configure should check
to see they both exist before comparing them!

It did try to check them; the 'Loc' script apparently got confused.
I don't know why it mentions 'echo.exe' instead of a plain 'echo'.

I am using msys

What is 'msys' ? That might explain the '.exe' suffix.

I am using msys and there is a file echo in /bin that calls builtin echo,
perhaps this is confusing Configure.

Yes, that's exactly it. Configure is assuming that the file 'echo' in /bin
is a working echo command. Configure doesn't test it. Again, there may confusion
due to the 'exe' suffix. I don't know why Configure is trying that.

perhaps this is confusing Configure. I will remove it... echo still works, I
will try running Configure again. That does not work. I want Configure to
use the builtin echo, but it does not recognize it. It says​:

I don't know where 'echo' is, and my life depends on it.
Go find a public domain implementation or fix your PATH setting!

Right. Configure is now bailing out at the stage when it's looking for
the /bin/echo executable. Configure assumes an 'echo' executable is
available, other than the built-in one. That's in part because Configure
was designed for Unix-like systems, and such systems have historically
always had a /bin/echo command, though different systems have slightly
differing versions.

The problem is to figure out why Configure couldn't figure out how to
use your /bin/echo command. I'll need to know more about whatever
'msys' is and what, exactly, you had that fooled Configure into
thinking there was a /bin/echo command.

--
  Andy Dougherty doughera@​lafayette.edu

From @JohnPeacock

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

  http​://www.mingw.org/msys.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

HTH

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748

From @Tux

On Fri, 28 Jan 2005 09​:30​:44 -0500, John Peacock <jpeacock@​rowman.com> wrote​:

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

http​://www\.mingw\.org/msys\.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

And how does it compare to DJGPP, which I experienced as a nightmare.

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.3, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
  AIX 4.3, SuSE 9.0 pro 2.4.21 & Win2k. http​://www.cmve.net/~merijn
Smoking perl​: smokers@​perl.org, perl QA​: http​://qa.perl.org
  reports to​: smokers-reports@​perl.org, perl-qa@​perl.org

From vkonovalov@spb.lucent.com

http​://www\.mingw\.org/msys\.shtml

I haven't had that much luck with it; CygWin is better
maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

And how does it compare to DJGPP, which I experienced as a nightmare.

Nightmare is WinCE port, and not DJGPP

:)

From stecmccarthy@hotpop.com

Good point, if Configure excepts the existence of an echo file in /bin for
the first test, but looks explicitly for /bin/echo.exe for the second test,
Configure might be confusing itself by changing the criteria. I have a file
in /bin that calls the bash builtin echo. Configure seems to think that a
builtin version is possible for the second test, but if that where the only
version, Configure would not even get that far, because it looks for
/bin/echo in the first test. Anyway this is the contects of the text file
/bin/echo, if that helps to clarify things below. By the way isn't it
standard in Unix that an executable does not have to have an extention to
work, unlike in Windows?
#!/bin/sh

# Copyright (C) 2002, Earnie Boyd

# mailto​:earnie@​users.sf.net

# This file is part of MSYS

# http​://www.mingw.org/msys.shtml

# File​: echo

echo "$@​"

Thanks, your thoughts are very interesting and point to a close familiarity
with Configure,
Stephen
P.S. The only consequence of this is that Configure prints /c in places
where a blank return in intended. Not earth shaking, but unnecessary.
----- Original Message -----
From​: "Andy Dougherty via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 8​:23 AM
Subject​: Re​: [perl #33948] configure checking echo

On Thu, 27 Jan 2005, Stephen wrote​:

# New Ticket Created by "Stephen"
# Please include the string​: [perl #33948]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=33948 >

The following message from Configure doesn't seem to make sense​:

Checking compatibility between /bin/echo.exe and builtin echo (if any)...
/home/Stephen/perl-5.8.6/Configure​: /bin/echo.exe​: No such file or
directory

This is a sign that Configure's gotten confused even earlier. Could you
please re-run Configure and look near the beginning where it says
something like

Locating common programs...
awk is in /usr/bin/awk.
cat is in /usr/bin/cat.
chmod is in /usr/bin/chmod.
comm is in /usr/bin/comm.
cp is in /usr/bin/cp.
echo is in /usr/bin/echo.
expr is in /usr/bin/expr.

What does it say for echo?

At this point, Configure thinks it has found a working 'echo' program;
later on, it doesn't go back and recheck that assumption. That's at the
root
of the later confusion.

They are not compatible! You are probably running ksh on a non-USG
system.
I'll have to use /bin/echo.exe instead of the builtin, since Bourne shell
doesn't
have echo built in and we may have to run some Bourne shell scripts.
That
means I'll have to use '\c' to suppress newlines now. Life is
ridiculous.

Yes, it does seem ridiculous. My shell has a builtin echo, but I do not
have
a function echo in the bin. Hence, there is no compatibily problem
between
them. The logic breaks down when Configure decides to use echo.exe
because I
don't have echo.exe. I mean, Configure decides to use echo.exe instead of
the builtin echo even if the reason they are different and therefore
incompatible is that there is no echo.exe available. Configure should
check
to see they both exist before comparing them!

It did try to check them; the 'Loc' script apparently got confused.
I don't know why it mentions 'echo.exe' instead of a plain 'echo'.

I am using msys

What is 'msys' ? That might explain the '.exe' suffix.

I am using msys and there is a file echo in /bin that calls builtin echo,
perhaps this is confusing Configure.

Yes, that's exactly it. Configure is assuming that the file 'echo' in
/bin
is a working echo command. Configure doesn't test it. Again, there may
confusion
due to the 'exe' suffix. I don't know why Configure is trying that.

perhaps this is confusing Configure. I will remove it... echo still
works, I
will try running Configure again. That does not work. I want Configure
to
use the builtin echo, but it does not recognize it. It says​:

I don't know where 'echo' is, and my life depends on it.
Go find a public domain implementation or fix your PATH setting!

Right. Configure is now bailing out at the stage when it's looking for
the /bin/echo executable. Configure assumes an 'echo' executable is
available, other than the built-in one. That's in part because Configure
was designed for Unix-like systems, and such systems have historically
always had a /bin/echo command, though different systems have slightly
differing versions.

The problem is to figure out why Configure couldn't figure out how to
use your /bin/echo command. I'll need to know more about whatever
'msys' is and what, exactly, you had that fooled Configure into
thinking there was a /bin/echo command.

--
Andy Dougherty doughera@​lafayette.edu

From @doughera88

On Fri, 28 Jan 2005, Stephen wrote​:

Good point, if Configure excepts the existence of an echo file in /bin for
the first test, but looks explicitly for /bin/echo.exe for the second test,
Configure might be confusing itself by changing the criteria.

Yes indeed. That's why I asked for the output of (that part of) Configure
so I could see what it thought it found.

/bin/echo, if that helps to clarify things below. By the way isn't it
standard in Unix that an executable does not have to have an extention to
work, unlike in Windows?

Yes, but on Windows the extension does matter, at least sometimes. If
you are running a Unix-ish environment under Windows (which I now
understand is the case here), then Configure tries to helpfully guess
whether or not to append an .exe to the command names. This guess is
stored in the Configure variable $_exe. That's apparently getting set
to '.exe' in your case, probably due to this code in Configure​:

  elif test -d c​:/. -o -n "$is_os2" ; then
  : OS/2 or cygwin
  _exe=".exe"

Then, later on, when Configure has found '/bin/echo', it unconditionally does

  eval $file=$xxx$_exe

(where file='echo' and xxx=/bin/echo). In short, since you're on
Windows, Configure expects the 'echo' command to be called echo.exe,
not just a plain 'echo'.

fine for everyone else all these years. I don't really know if that
$_exe is really required, nor do I know what would happen if we dropped
the $_exe there. I suppose we could try it and see, but the current
version has been working well for many years for at least some users,
so we do have to be careful.

I suppose we could put in some sort of additional test -f $xxx$_exe
before unconditionally setting the variable. That would
probably be safe and wouldn't break anything.

--
  Andy Dougherty doughera@​lafayette.edu

From RandyS@ThePierianSpring.org

H.Merijn Brand wrote​:

On Fri, 28 Jan 2005 09​:30​:44 -0500, John Peacock <jpeacock@​rowman.com> wrote​:

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

http​://www.mingw.org/msys.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

And how does it compare to DJGPP, which I experienced as a nightmare.

I haven't looked at it in a couple years, but it is a fork of Cygwin
with a lot of the fat trimmed. It was meant to be a minimal environment
with the only goal being to run ./Configure scripts under Windows. When
I was keeping up, it was very actively maintained by its creator, Ernie
Boyd, and it was strongly linked with the MinGW project. IIRC, it was
distributed with a version of (cygwin-ish?) perl. Given its goal, I'm
not sure why anyone would want to build perl with msys as opposed to a
native win32 build.

Randy.

From @doughera88

On Thu, 27 Jan 2005, Stephen wrote​:

                                         It is probably not a high

priority, but Configure could use a little update. For instance, it
includes sys/file.h instead of fcntl.h when sys/file.h in only a dummy
that call fcntl.h anyway​:

Well, it might be on your system, but it's certainly not everywhere.

Your broader point is correct -- Configure in many little ways still shows
its BSDish origins. However, it generally works, so there's little
incentive to muck with things that work :-).

--
  Andy Dougherty doughera@​lafayette.edu

From stecmccarthy@hotpop.com

Like Cygwin, Msys runs on a dll that allows it to provied the user with a
bash sell in Windows, but unlike Cygwin, it lets MinGW compile programs
independently of it. The benefit is that it allows the user to run configure
scripts and still compile using the regular native version of MinGW, Cygwin
has its own version of MinGW and indeed of everything else, I want to
operate a bash shell and still compile programs that will run in a cmd.exe
shell. Cygwin does not offer that functionality. For people who start out
compiling with MinGW in a cmd.exe shell, it is not tempting to migrate to
CygWin, I make that choice years ago. It is tremendously helpfuf,
instructive to be able to run Configure, if only to learn more about what is
involved in compiling Perl.

Right now I am compling Perl using dmake in the cmd.exe shell on the one
hand and using Configure to rewrite makefile.mk, config.gc, and Config_H.gc
on the other hand. Recently, I ran into an interesting snag that config.gc
must have the following logically conflicting lines in order to compile in
Windows due to the absence of a usable DIR struct in dirent.h​:

direntrytype='struct direct'
i_dirent='define'

Configure assumes direntrytype='struct dirent' if dirent.h exists, but in
Windows 'striuct dirent' is incompatible with the Unix version. This is the
way config.gc looks as shipped in perl-5.8.6 and is correct, unless you want
to remove the dependency on dirent.h for the Windows compile entirely or
possibly take away Configures assuption that 'struct dirent' is usable if
dirent.h exists, but it is an example of where the output from Configure
must be hand edited for a Windows compile to compile properly. Personally I
think MinGW should not ship with a version of both direct.h and dirent.h, as
that is bound to confuse almost any Unix configure script.
Basically, I am trying to have the best of both worlds, using Configure to
guide me in updating and tailoring a Windows compile on my computer. My
pipedream is that an msys user can run Configure with no options, msys will
pop up as a system, those defaults will be used successfully and perl will
compile for Windows in a bash shell, using the default Unix directory
structure​: --prefix=/usr/local. The first challenge toward that goal is to
figure out what those defaults need to be. So it is necessary for me to
reinvent the wheel, since someone already figured most of this when creating
config.gc and config_H.gc. Most of it, but not for running bash using
gnumake, although I really do appreciate dmake now that I am running it, its
just that msys comes with its own version of make and it would be nice to
make the process more transparent to the user. The dmake option is *the*
answer for people who use MinGW in the cmd.exe shell.

The final problem I find is that htonl is found in sys/socket.h in Windows,
but Configure does not look for it there, so
d_htonl='define'

is the second edit needed.

This is the Configure command line I use so far​:
/home/Stephen/perl/perl-5.8.6/Configure -Dprefix='c​:/msys/1.0/local' -Doptimize="-O3
-march=pentium4 -malign-double" -Dlibs='-lgdbm -lm' -Dcc=gcc -Dso=dll -Uusenm
-Dusemymalloc -Dusethreads -Uinstallusrbinperl -Ubincompat5005 -Dyacc='bison
-y' -Accflags="-DPERL_DEBUGGING_MSTATS -DPERL_IMPLICIT_CONTEXT -DPERL_MSVCRT_READFIX"
-Dlibpth="/usr/local/lib
/usr/mingw/lib" -Dosname=Windows_NT -Dosvers=5.1 -Dgidtype=long -Duidtype=long
-Dextras="Compress​::Zlib Bundle​::LWP
DBI" -Dcf_email="stecmccarthy@​hotpop.com" -Dfirstmakefile=GNUmakefile -des

Under msys all programs in /bin must use the msys-1.0.dll, so the programs
I compile are put in /usr/local/bin by default. So to recap, like CygWIN,
msys does rely on its own dll to function, but unlike CygWIN it allows MinGW
to compile programs that don't rely on it.

I also used to include the define -UWIN32, but now I am focusing on
producing a config.sh that I can use in place of config.gc.

I realize that this is too long because I am bringing up multiple issues
relating to using Configure in a WIN32 environment in the same thread.
Unfortunately, I am good enough at juggling multiple parallel ideas in my
own head that I have a hard time reigning it in sometmes. I assure you, I do
respect the need to stay on topic in a thead and do have one eye on that
issue of netiquette. Just respond, please, to whatever part of this thread
interests you and feel free to ignore the rest. I will not be offended.

Thank you,
Stephen

----- Original Message -----
From​: "John Peacock via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 8​:30 AM
Subject​: Re​: [perl #33948] configure checking echo

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

http​://www.mingw.org/msys.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

HTH

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748

From stecmccarthy@hotpop.com

It does have the ability to create native Win32 apps that don't have
dependencies on other libraries.
Opps, you did mention that didn't you, I focused on the previous sentence,
sorry.
For me the ability to create native apps is a deal breaker, So I never
really investigated cygwin, even though I use msys when I want to use a
program in the bash shell anyway, like GCL for instance.

Stephen

----- Original Message -----
From​: "John Peacock via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 8​:30 AM
Subject​: Re​: [perl #33948] configure checking echo

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

http​://www.mingw.org/msys.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

HTH

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748

From stecmccarthy@hotpop.com

I agree.

And what is really hard is so often WIN32 is treated as equivalent to MSVC
or DJGPP which complicates porting to Windows using gcc considerably. Often,
it is safer to -UWIN32 and compile it as a Unix program, AKCL was ported to
dos as a unix program years ago, which greatly facilitated porting GCL to
msys today. But for a program that uses DIR and htonl like Perl, it is not
possible to use the unix versions of that part of the code. I do appeal to
programmers to name your defines carefully, if something only applies to
DJGPP, then say #ifdef __DJGPP__ instead of #ifdef WIN32 in the source code.
This procedure allows porting a unix program to multiple WIN compilers.

For an example that I personally worked on, check out bladeenc system.h. It
allows you to compile with MinGW as __GNUC__ or Borland or MSVC.

Stephen
from Minnesota (as I said when working on bladeenc)

----- Original Message -----
From​: "H. Merijn Brand via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 8​:41 AM
Subject​: Re​: [perl #33948] configure checking echo

On Fri, 28 Jan 2005 09​:30​:44 -0500, John Peacock <jpeacock@​rowman.com>
wrote​:

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

http​://www.mingw.org/msys.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

And how does it compare to DJGPP, which I experienced as a nightmare.

--
H.Merijn Brand Amsterdam Perl Mongers (http​://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.3, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11,
AIX 4.3, SuSE 9.0 pro 2.4.21 & Win2k. http​://www.cmve.net/~merijn
Smoking perl​: smokers@​perl.org, perl QA​: http​://qa.perl.org
reports to​: smokers-reports@​perl.org, perl-qa@​perl.org

From stecmccarthy@hotpop.com

Maybe I could rename the file '/bin/echo.exe', Remember, I am still running
it from bash, so it should not matter that bash is running in Windows. The
version of echo is a part of msys and won't run outside of bash. I mean why
doesn't Configure get confused if someone is running Linux or Unix with only
a built-in echo and no executable? Mmmm, I'm gettng it now. Flex compiled
fine on msys without adding an extension. It still works when I call it from
bash. Anyone running a bash environment can get away with not using an
extention whether or not he is using Windows. The problem with msys may be
that it is the first program to embrace normal bash rules in a WIN env. When
would ignoring the ext cause problems?

Stephen
----- Original Message -----
From​: "Andy Dougherty via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 11​:11 AM
Subject​: Re​: [perl #33948] configure checking echo

On Fri, 28 Jan 2005, Stephen wrote​:

Good point, if Configure excepts the existence of an echo file in /bin
for
the first test, but looks explicitly for /bin/echo.exe for the second
test,
Configure might be confusing itself by changing the criteria.

Yes indeed. That's why I asked for the output of (that part of) Configure
so I could see what it thought it found.

/bin/echo, if that helps to clarify things below. By the way isn't it
standard in Unix that an executable does not have to have an extention to
work, unlike in Windows?

Yes, but on Windows the extension does matter, at least sometimes. If
you are running a Unix-ish environment under Windows (which I now
understand is the case here), then Configure tries to helpfully guess
whether or not to append an .exe to the command names. This guess is
stored in the Configure variable $_exe. That's apparently getting set
to '.exe' in your case, probably due to this code in Configure​:

elif test -d c​:/. -o -n "$is_os2" ; then
: OS/2 or cygwin
_exe=".exe"

Then, later on, when Configure has found '/bin/echo', it unconditionally
does

eval $file=$xxx$_exe

(where file='echo' and xxx=/bin/echo). In short, since you're on
Windows, Configure expects the 'echo' command to be called echo.exe,
not just a plain 'echo'.

fine for everyone else all these years. I don't really know if that
$_exe is really required, nor do I know what would happen if we dropped
the $_exe there. I suppose we could try it and see, but the current
version has been working well for many years for at least some users,
so we do have to be careful.

I suppose we could put in some sort of additional test -f $xxx$_exe
before unconditionally setting the variable. That would
probably be safe and wouldn't break anything.

--
Andy Dougherty doughera@​lafayette.edu

From stecmccarthy@hotpop.com

Your right, it is a way to run configure scripts while compiling a native
win32 build at the same time. I want perl to be placed where some common gnu
programs expect to find it by default. Studying Configure vs makefile.mk for
a windows build has helped me to understand the build options better, so I
am able to make informed decisions on how to edit makefile.mk.

But there are some things you cannot configure for a windows build that you
actually could if I could get Configure and makefile.mk to lineup. More
accurately -​: to get config.sh to line up with makefile.mk, using it to
create a custom config.gc. config.gc is a copy of config.sh, edited to make
up where Configure needs help. So now you know how the gcc port of windows
in the win32 directory using dmake works.

Right now my main goal it to create a hint file for msys. Well, my main goal
really is getting it to compile, which I did. A secondary goal is to get
things that you can do with Configure like -Dextras="Compress​::Zlib
Bundle​::LWP DBI" -Dlibs='-lgdbm -lm' to work.

Stephen
----- Original Message -----
From​: "Randy W. Sims via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 11​:29 AM
Subject​: Re​: [perl #33948] configure checking echo

H.Merijn Brand wrote​:

On Fri, 28 Jan 2005 09​:30​:44 -0500, John Peacock <jpeacock@​rowman.com>
wrote​:

Andy Dougherty wrote​:

What is 'msys' ? That might explain the '.exe' suffix.

msys is the Minimal System for MinGW​:

http​://www.mingw.org/msys.shtml

I haven't had that much luck with it; CygWin is better maintained. It
does have the ability to create native Win32 apps that don't have
dependencies on other libraries. YMMV

And how does it compare to DJGPP, which I experienced as a nightmare.

I haven't looked at it in a couple years, but it is a fork of Cygwin
with a lot of the fat trimmed. It was meant to be a minimal environment
with the only goal being to run ./Configure scripts under Windows. When
I was keeping up, it was very actively maintained by its creator, Ernie
Boyd, and it was strongly linked with the MinGW project. IIRC, it was
distributed with a version of (cygwin-ish?) perl. Given its goal, I'm
not sure why anyone would want to build perl with msys as opposed to a
native win32 build.

Randy.

From stecmccarthy@hotpop.com

I don't really think it is necessary to change anything relating to echo.
However, at the top of my wish list is looking for htonl in sys/socket.h as
that is where you will find it on a Windows platform, but of course if you
did that, it would only be a part of the solution and the little tests
Configure compiles might not be compiling under Windows anyway. If you don't
link to libmsvcrt.a you get an error finding WinMain@​16. At least I think
that is the solution.

The second thing on the wishlist is not assuming a usable 'struct dirent'
given dirent.h. MinGW has that and direct.h. Although I am not an authority,
I think having both might inevitably confuse any configure script. The
problem is MinGW is not written for msys, msys is written for MinGW which is
primarily intended to be used in cmd, not bash.

Anyway, these are just ideas to put out there to make you more aware of the
details if at any time it seems feasible to make Configure Windows friendly.
Right now there is not much of a push for it in the Linux community, but at
some point it will become obvious there are advantages to helping to port
the great software written for Linux to Windows. Although of course has been
ported to windows and I did succeed in porting Perl-5.8.6. Some of the
newest options are not included though. If it worked with Configure, the
Windows compile would stay uptodate automatically. That is the advantage,
but it is still a decent compile using the newest verion of Perl. No
complaints. I think I might check out comp.lang.perl.misc for some of my
further questions.

Stephen
----- Original Message -----
From​: "Andy Dougherty via RT" <perlbug-followup@​perl.org>
To​: <stecmccarthy@​hotpop.com>
Sent​: Friday, January 28, 2005 11​:38 AM
Subject​: Re​: [perl #33948] configure checking echo

On Thu, 27 Jan 2005, Stephen wrote​:

                                         It is probably not a high

priority, but Configure could use a little update. For instance, it
includes sys/file.h instead of fcntl.h when sys/file.h in only a dummy
that call fcntl.h anyway​:

Well, it might be on your system, but it's certainly not everywhere.

Your broader point is correct -- Configure in many little ways still shows
its BSDish origins. However, it generally works, so there's little
incentive to muck with things that work :-).

--
Andy Dougherty doughera@​lafayette.edu

From @nwc10

On Sat, Jan 29, 2005 at 11​:28​:05AM -0600, Stephen wrote​:

Anyway, these are just ideas to put out there to make you more aware of the
details if at any time it seems feasible to make Configure Windows
friendly. Right now there is not much of a push for it in the Linux

No-one on the perl5-porters mailing list is going to object to the principle
of making Configure more portable (although it won't all be plain sailing,
as specific changes to the implementation may raise concerns, given that
"more portable" implies "not breaking existing platforms")

However, I'm unaware of anyone on the list using msys, and as everyone
working on perl5 is volunteering, there's no reason why the existing
contributors to the core have any reason to initiate making Configure work
better with msys. Hence if improvements are to be made, they need to be
promoted by someone with a direct interest in them, such as a user of msys
who will benefit from it.

No push doesn't mean hostility. It just means that everyone has more than
enough existing things to do with their free time.

Nicholas Clark

From @jkeenan

On Mon, 31 Jan 2005 14​:58​:18 GMT, nicholas wrote​:

On Sat, Jan 29, 2005 at 11​:28​:05AM -0600, Stephen wrote​:

Anyway, these are just ideas to put out there to make you more aware
of the
details if at any time it seems feasible to make Configure Windows
friendly. Right now there is not much of a push for it in the Linux

No-one on the perl5-porters mailing list is going to object to the
principle
of making Configure more portable (although it won't all be plain
sailing,
as specific changes to the implementation may raise concerns, given
that
"more portable" implies "not breaking existing platforms")

However, I'm unaware of anyone on the list using msys, and as everyone
working on perl5 is volunteering, there's no reason why the existing
contributors to the core have any reason to initiate making Configure
work
better with msys. Hence if improvements are to be made, they need to
be
promoted by someone with a direct interest in them, such as a user of
msys
who will benefit from it.

No push doesn't mean hostility. It just means that everyone has more
than
enough existing things to do with their free time.

Nicholas Clark

There has been no correspondence in this RT in nearly 13 years. Unless someone speaks up soon to argue for continued investigation of this issue, it should be closed.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @jkeenan

On Fri, 29 Dec 2017 13​:36​:56 GMT, jkeenan wrote​:

On Mon, 31 Jan 2005 14​:58​:18 GMT, nicholas wrote​:

On Sat, Jan 29, 2005 at 11​:28​:05AM -0600, Stephen wrote​:

Anyway, these are just ideas to put out there to make you more
aware
of the
details if at any time it seems feasible to make Configure Windows
friendly. Right now there is not much of a push for it in the Linux

No-one on the perl5-porters mailing list is going to object to the
principle
of making Configure more portable (although it won't all be plain
sailing,
as specific changes to the implementation may raise concerns, given
that
"more portable" implies "not breaking existing platforms")

However, I'm unaware of anyone on the list using msys, and as
everyone
working on perl5 is volunteering, there's no reason why the existing
contributors to the core have any reason to initiate making Configure
work
better with msys. Hence if improvements are to be made, they need to
be
promoted by someone with a direct interest in them, such as a user of
msys
who will benefit from it.

No push doesn't mean hostility. It just means that everyone has more
than
enough existing things to do with their free time.

Nicholas Clark

There has been no correspondence in this RT in nearly 13 years.
Unless someone speaks up soon to argue for continued investigation of
this issue, it should be closed.

Thank you very much.

No further correspondence received; closing.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@jkeenan - Status changed from 'open' to 'rejected'