GNU logs - #23058, boring messages

Message sent to bug-libtool@HIDDEN:

Subject: bug#23058: Bug found in libtool make process
Resent-From: "Villeneuve, Donald H" <donald.h.villeneuve@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 19 Mar 2016 00:45:02 +0000
Resent-Message-ID: <handler.23058.B.14583482821264 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 23058 <at> debbugs.gnu.org
From: "Villeneuve, Donald H" <donald.h.villeneuve@HIDDEN>
Thread-Topic: Bug found in libtool make process
Thread-Index: AdGBcGK1OQIxRtvFR4GGjspT3O5G6g==
Date: Fri, 18 Mar 2016 23:55:51 +0000
Message-ID: <902B52500FBE5E40BD36BB137A02A7164DC8C6@HIDDEN>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
 boundary="_000_902B52500FBE5E40BD36BB137A02A7164DC8C6ORSMSX111amrcorpi_"
MIME-Version: 1.0
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--_000_902B52500FBE5E40BD36BB137A02A7164DC8C6ORSMSX111amrcorpi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
We build and use libtool for one of the products we are working on.

In the course of build libtool the following was noticed:


1)      Do as usual a configure  --> everything seems fine

2)      export U=3Dabcxyz_idoNotcare_whatitis

3)      make

The make will fail because in the course of its run, it will use a variable=
 called $U.
This bug was noticed when installing libtool 2.4.2 under
Linux-2.6.32-504.el6.x86_64-x86_64-with-redhat-6.7-Santiago
GNU Make 3.81

The fix is clear: Someone must not use U as a variable name.  In this case,=
 the customer was using the variable U as follows:
    export U=3D~/util
So as a shortcut for their utility directory, which seems to be an admissib=
le use case.

I've not check more recent versions of libtool against this bug.  But as we=
 move away from 2.4.2, it would be not to have to worry about this one.
Thanks.

If you have any further questions, more details can be provided.
Donald


--_000_902B52500FBE5E40BD36BB137A02A7164DC8C6ORSMSX111amrcorpi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:324629404;
	mso-list-type:hybrid;
	mso-list-template-ids:888158028 67698705 67698713 67698715 67698703 676987=
13 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi,<o:p></o:p></p>
<p class=3D"MsoNormal">We build and use libtool for one of the products we =
are working on.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">In the course of build libtool the following was not=
iced:<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">1)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>Do as usual a configure&nbsp; <span style=3D"font-f=
amily:Wingdings">
&agrave;</span> everything seems fine<o:p></o:p></p>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">2)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>export U=3Dabcxyz_idoNotcare_whatitis<o:p></o:p></p=
>
<p class=3D"MsoListParagraph" style=3D"text-indent:-.25in;mso-list:l0 level=
1 lfo1"><![if !supportLists]><span style=3D"mso-list:Ignore">3)<span style=
=3D"font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span><![endif]>make<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The make will fail because in the course of its run,=
 it will use a variable called $U.<o:p></o:p></p>
<p class=3D"MsoNormal">This bug was noticed when installing libtool 2.4.2 u=
nder <o:p>
</o:p></p>
<p class=3D"MsoNormal">Linux-2.6.32-504.el6.x86_64-x86_64-with-redhat-6.7-S=
antiago<o:p></o:p></p>
<p class=3D"MsoNormal">GNU Make 3.81<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">The fix is clear: Someone must not use U as a variab=
le name.&nbsp; In this case, the customer was using the variable U as follo=
ws:<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp;&nbsp; export U=3D~/util<o:p></o:p></p>
<p class=3D"MsoNormal">So as a shortcut for their utility directory, which =
seems to be an admissible use case.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I&#8217;ve not check more recent versions of libtool=
 against this bug.&nbsp; But as we move away from 2.4.2, it would be not to=
 have to worry about this one.<o:p></o:p></p>
<p class=3D"MsoNormal">Thanks.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">If you have any further questions, more details can =
be provided.<o:p></o:p></p>
<p class=3D"MsoNormal">Donald<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_902B52500FBE5E40BD36BB137A02A7164DC8C6ORSMSX111amrcorpi_--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "Villeneuve, Donald H" <donald.h.villeneuve@HIDDEN>
Subject: bug#23058: Acknowledgement (Bug found in libtool make process)
Message-ID: <handler.23058.B.14583482821264.ack <at> debbugs.gnu.org>
References: <902B52500FBE5E40BD36BB137A02A7164DC8C6@HIDDEN>
X-Gnu-PR-Message: ack 23058
X-Gnu-PR-Package: libtool
Reply-To: 23058 <at> debbugs.gnu.org
Date: Sat, 19 Mar 2016 00:45:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-libtool@HIDDEN

If you wish to submit further information on this problem, please
send it to 23058 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
23058: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D23058
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-libtool@HIDDEN:

Subject: bug#23058: Bug found in libtool make process
Resent-From: Peter Rosin <peda@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-libtool@HIDDEN
Resent-Date: Sat, 19 Mar 2016 21:42:01 +0000
Resent-Message-ID: <handler.23058.B23058.145842366211735 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "Villeneuve, Donald H" <donald.h.villeneuve@HIDDEN>,  23058 <at> debbugs.gnu.org
Message-ID: <56EDC768.4080605@HIDDEN>
Date: Sat, 19 Mar 2016 22:40:56 +0100
From: Peter Rosin <peda@HIDDEN>
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
References: <902B52500FBE5E40BD36BB137A02A7164DC8C6@HIDDEN>
In-Reply-To: <902B52500FBE5E40BD36BB137A02A7164DC8C6@HIDDEN>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>



On 2016-03-19 00:55, Villeneuve, Donald H wrote:
> Hi,
> We build and use libtool for one of the products we are working on.
>  
> In the course of build libtool the following was noticed:
>  
> 1)      Do as usual a configure  � everything seems fine
> 2)      export U=abcxyz_idoNotcare_whatitis
> 3)      make
>  
> The make will fail because in the course of its run, it will use a variable called $U.
> This bug was noticed when installing libtool 2.4.2 under
> Linux-2.6.32-504.el6.x86_64-x86_64-with-redhat-6.7-Santiago
> GNU Make 3.81
>  
> The fix is clear: Someone must not use U as a variable name.  In this case, the customer was using the variable U as follows:
>     export U=~/util
> So as a shortcut for their utility directory, which seems to be an admissible use case.
>  
> I�ve not check more recent versions of libtool against this bug.  But as we move away from 2.4.2, it would be not to have to worry about this one.
> Thanks.
>  
> If you have any further questions, more details can be provided.
> Donald

This is not a libtool bug, it is caused by some bad interaction
between autoconf and automake in the code for support of pre-ANSI
compilers. See [1] for an old dup of your report. Automake has
removed support for pre-ANSI compilers since a couple of years,
maybe it is time for autoconf to follow?

Cheers,
Peter

http://lists.gnu.org/archive/html/bug-autoconf/2010-02/msg00013.html

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.