[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[support #100058] 1.4 - $buildir-path may not contain "~"
From: |
Peter O'Gorman |
Subject: |
[support #100058] 1.4 - $buildir-path may not contain "~" |
Date: |
Wed, 24 Nov 2004 10:25:47 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11 |
This mail is an automated notification from the support tracker
of the project: GNU Libtool.
/**************************************************************************/
[support #100058] Latest Modifications:
Changes by:
Peter O'Gorman <address@hidden>
'Date:
Wed 11/24/2004 at 15:14 (Japan)
------------------ Additional Follow-up Comments ----------------------------
And to keep Gary happy :)
I fixed this particular bug with:
<http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/Attic/ltmain.in.diff?r1=1.357&r2=1.358&search=None&hideattic=1>
It was later cleaned up a little and backported to branch-1-5 for Scott's 1.5.2
release.
/**************************************************************************/
[support #100058] Full Item Snapshot:
URL: <http://savannah.gnu.org/support/?func=detailitem&item_id=100058>
Project: GNU Libtool
Submitted by: Guido Draheim
On: Thu 06/14/2001 at 06:10
Category: None
Priority: 5 - Normal
Severity: 3 - Ordinary
Resolution: Done
Privacy: Public
Assigned to: pogma
Originator Email:
Status: Closed
Summary: 1.4 - $buildir-path may not contain "~"
Original Submission:
With the change from 1.3.5 to 1.4
all project builds broke. It boiled
down to the project-path to have a
"~" somewhere in the middle, i.e.
some/project~0.1.3/dir which is
perfectly legal, but at some point
during mode=linking, the libtool
script will barf at "0.1.3/dir"
being nonexistent - it probably
has to do with libtool storing some
command-sequences using a IFS="~"
(delimiter instead of a IFS=";").
Note that the project-path is not
my choice but the one of the local
source-repository system, and that
it does not help to use symlinks to
circumvent the problem - libtool
seems to resolve names for relative
paths to the real-path, i.e. sth.
like -L.. will contain a "~" later.
Since earlier versions had allowed
the buildpath to contain "~", it is
probably possible to fix this issue,
but what to do before that? Is there
a way to get around the problem now?
Follow-up Comments
------------------
-------------------------------------------------------
Date: Wed 11/24/2004 at 15:14 By: Peter O'Gorman <pogma>
And to keep Gary happy :)
I fixed this particular bug with:
<http://savannah.gnu.org/cgi-bin/viewcvs/libtool/libtool/Attic/ltmain.in.diff?r1=1.357&r2=1.358&search=None&hideattic=1>
It was later cleaned up a little and backported to branch-1-5 for Scott's 1.5.2
release.
-------------------------------------------------------
Date: Wed 11/24/2004 at 13:42 By: Peter O'Gorman <pogma>
I am pretty sure that this is fixed in libtool-1.5.2 and later.
Closing.
-------------------------------------------------------
Date: Sat 06/16/2001 at 17:15 By: Guido Draheim <guidod>
Gary V.Vaughan wrote:
> Perhaps the problem will go away when
> we have a binary ltmain in a couple of
> releases?
> In the mean while, I think the only workaround
> is to not use '~' in pathnames.
*sigh* ... actually, I just don't know why it did
work in 1.3.x and it must be left as is in 1.4 - well,
then again, libtool gained functionality...
btw, after a bit of trial-and-error, I am using now
a builddir outside the source-archive where the
original files are symlinked. That way any updates
to the files through the archive (from co-developments)
are directly reflected in the builddir, and all the
real-paths of directories do not contain a "~".
Hopefully, the "~" can be solved later on...
For detailed info, follow this link:
<http://savannah.gnu.org/support/?func=detailitem&item_id=100058>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/