Date: Tue, 25 May 1999 11:08:22 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: djgpp-workers AT delorie DOT com
Subject: ["Gary V. Vaughan" <gary AT oranda DOT demon DOT co DOT uk>] RE: Programs differing only by ".exe" suffix: subtle Libtool 1.3 (fwd)
Message-ID: <Pine.SUN.3.91.990525110503.24405Q-210000@is>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="=-=-="
Content-ID: <Pine DOT SUN DOT 3 DOT 91 DOT 990525110503 DOT 24405R AT is>
Reply-To: djgpp-workers AT delorie DOT com

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime AT docserver DOT cac DOT washington DOT edu for more info.

--=-=-=
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine DOT SUN DOT 3 DOT 91 DOT 990525110503 DOT 24405S AT is>

Perhaps someone who knows more than I do about Autoconf and libtool could
see if this has any implication on DJGPP, and if so, talk to people who
are involved in developing libtool? 

Thanks.

---------- Forwarded message ----------
Date: Sun, 23 May 1999 21:18:37 +0100 (BST)
From: "Gary V. Vaughan" <gary AT oranda DOT demon DOT co DOT uk>
To: Thomas Tanner <tanner AT gmx DOT de>
Subject: RE: Programs differing only by ".exe" suffix: subtle Libtool 1.3
Cc: bug-libtool AT gnu DOT org, Automake List <automake AT gnu DOT org>,
        "Matthew D. Langston" <langston AT SLAC DOT Stanford DOT EDU>
Resent-Message-ID: <"AUX52.0.-f3.FBQIt"@mescaline.gnu.org>
Resent-From: automake AT gnu DOT org
X-Mailing-List: <automake AT gnu DOT org> archive/latest/2324
X-Loop: automake AT gnu DOT org
Precedence: list
Resent-Sender: automake-request AT gnu DOT org
X-Content-Length: 2172
X-UIDL: 1da489416104f8d04b85f78a76453ec9
Lines: 43
Xref: titan.progiciels-bpi.ca prog.libtool:3047

On 23-May-99 Thomas Tanner wrote:
> 
> On 22-May-99 Matthew D. Langston wrote:
>> In a nutshell, an Automake/Libtool package becomes "broken" when two
>> programs (i.e. in some Automake "_PROGRAMS" primary) differ in their
>> names only by the suffix ".exe".  For example, the following snippet
>> from `Makefile.am' works as expected:
> 
>  Thanks. Fixed.
>  
>> I recently came across this bug while "Autoconfing" a package called
>> ROOT (an analysis package for High Energy Physics).  My "Autoconfed"
>> version of ROOT creates two programs named "root" and "root.exe".  Since
>> I am packaging a 3rd party package, I have no control over the names of
>> these two programs.  I have had to fall back to Libtool 1.2 for now.
> 
>  Using prog and prog.exe at the same time isn't really portable.
>  On CygWin libtool has to strip off the .exe suffix from the
>  wrapper script, i.e., prog == prog.exe.

Infact it is worse than that.  It is non-portable to rely on when a .exe suffix
might be found at all.  Because of the stupid file extension associations in
win32, anything will an exe suffix is assumed (at the OS level) to be a binary
executable, so depending on whether or not a bin_PROGRAMS target is compiled
statically or dynamically, it may end up being a binary with an exe suffix, or
a wrapper script which cannot have an exe suffix (or it will not run under
win32).

Automake and libtool go to some lengths to manage suffixes in a way that will
work transparently (except for needing AC_EXEEXT), and trying to manage using
exe suffixes in a different way within a package can only lead to a conflict of
interests which will make it all the more difficult for someone to port the
package to win32.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _  email:gary AT oranda DOT demon DOT co DOT uk
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary AT gnu DOT org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                pgp-2 public key:
http://www.oranda.demon.co.uk               http://www.oranda.demon.co.uk/pgp
--=-=-=
Content-Type: MESSAGE/RFC822
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine DOT SUN DOT 3 DOT 91 DOT 990525110503 DOT 24405T AT is>

X-From-Line: gary AT oranda DOT demon DOT co DOT uk  Sun May 23 21:18:37 1999
Return-Path: <pinard AT IRO DOT UMontreal DOT CA>
Received: from IRO.UMontreal.CA by icule.progiciels-bpi.ca (8.8.8/8.8.8) with UUCP id PAA01652 for pinard AT icule DOT progiciels-bpi DOT ca; Mon, 24 May 1999 15:27:31 -0400
Received: from jupiter.rtsq.qc.ca (rtsq.grics.qc.ca [199.84.132.81]) by ariel.progiciels-bpi.ca (950413.SGI.8.6.12/950213.SGI) via ESMTP id PAA29051 for <pinard AT icule DOT progiciels-bpi DOT ca>; Mon, 24 May 1999 15:10:50 -0700
Received: from mercure.IRO.UMontreal.CA by jupiter.rtsq.qc.ca (8.8.8/8.8.8) with ESMTP id PAA23963 for <pinard AT icule DOT progiciels-bpi DOT ca>; Mon, 24 May 1999 15:08:11 -0400
Received: (from pinard AT localhost)
	by mercure.IRO.UMontreal.CA (8.9.1/8.9.3) id PAA26641
	for pinard AT icule DOT progiciels-bpi DOT ca; Mon, 24 May 1999 15:08:10 -0400
Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
	by mercure.IRO.UMontreal.CA (8.9.1/8.9.3) with ESMTP id PAA26638
	for <pinard AT iro DOT umontreal DOT ca>; Mon, 24 May 1999 15:08:09 -0400
Received: (from slist AT localhost)
	by mescaline.gnu.org (8.9.1a/8.9.1) id PAA14981;
	Mon, 24 May 1999 15:04:48 -0400
Resent-Date: Mon, 24 May 1999 15:04:48 -0400
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38])
	by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id PAA14926;
	Mon, 24 May 1999 15:04:26 -0400
Received: from [194.222.82.6] (helo=ryukin.goldfish)
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 10m01O-000Ccw-0A; Mon, 24 May 1999 19:04:22 +0000
Received: from oranda.goldfish [192.168.0.2] 
	by ryukin.goldfish with esmtp (Exim 2.05 #1 (Debian))
	id 10lfeE-0001Wb-00; Sun, 23 May 1999 22:19:06 +0100
X-Gnus-Mail-Source: pop:pinard AT icule DOT progiciels-bpi DOT ca
Message-ID: <XFMail DOT 990523211837 DOT gary AT oranda DOT demon DOT co DOT uk>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <NailMail DOT 990523121313 DOT tanner AT gmx DOT de>
Date: Sun, 23 May 1999 21:18:37 +0100 (BST)
From: "Gary V. Vaughan" <gary AT oranda DOT demon DOT co DOT uk>
To: Thomas Tanner <tanner AT gmx DOT de>
Subject: RE: Programs differing only by ".exe" suffix: subtle Libtool 1.3
Cc: bug-libtool AT gnu DOT org, Automake List <automake AT gnu DOT org>,
        "Matthew D. Langston" <langston AT SLAC DOT Stanford DOT EDU>
Resent-Message-ID: <"AUX52.0.-f3.FBQIt"@mescaline.gnu.org>
Resent-From: automake AT gnu DOT org
X-Mailing-List: <automake AT gnu DOT org> archive/latest/2324
X-Loop: automake AT gnu DOT org
Precedence: list
Resent-Sender: automake-request AT gnu DOT org
X-Content-Length: 2172
X-UIDL: 1da489416104f8d04b85f78a76453ec9
Lines: 43
Xref: titan.progiciels-bpi.ca prog.libtool:3047

On 23-May-99 Thomas Tanner wrote:
> 
> On 22-May-99 Matthew D. Langston wrote:
>> In a nutshell, an Automake/Libtool package becomes "broken" when two
>> programs (i.e. in some Automake "_PROGRAMS" primary) differ in their
>> names only by the suffix ".exe".  For example, the following snippet
>> from `Makefile.am' works as expected:
> 
>  Thanks. Fixed.
>  
>> I recently came across this bug while "Autoconfing" a package called
>> ROOT (an analysis package for High Energy Physics).  My "Autoconfed"
>> version of ROOT creates two programs named "root" and "root.exe".  Since
>> I am packaging a 3rd party package, I have no control over the names of
>> these two programs.  I have had to fall back to Libtool 1.2 for now.
> 
>  Using prog and prog.exe at the same time isn't really portable.
>  On CygWin libtool has to strip off the .exe suffix from the
>  wrapper script, i.e., prog == prog.exe.

Infact it is worse than that.  It is non-portable to rely on when a .exe suffix
might be found at all.  Because of the stupid file extension associations in
win32, anything will an exe suffix is assumed (at the OS level) to be a binary
executable, so depending on whether or not a bin_PROGRAMS target is compiled
statically or dynamically, it may end up being a binary with an exe suffix, or
a wrapper script which cannot have an exe suffix (or it will not run under
win32).

Automake and libtool go to some lengths to manage suffixes in a way that will
work transparently (except for needing AC_EXEEXT), and trying to manage using
exe suffixes in a different way within a package can only lead to a conflict of
interests which will make it all the more difficult for someone to port the
package to win32.

Cheers,
        Gary.
-- 
  ___              _   ___   __              _  email:gary AT oranda DOT demon DOT co DOT uk
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       gary AT gnu DOT org 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                pgp-2 public key:
http://www.oranda.demon.co.uk               http://www.oranda.demon.co.uk/pgp

--=-=-=
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine DOT SUN DOT 3 DOT 91 DOT 990525110503 DOT 24405U AT is>

=0D
--=20=0D
Fran=E7ois Pinard   http://www.iro.umontreal.ca/~pinard=0D

--=-=-=--