[support #100058] 1.4 - $buildir-path may not contain "~"

[Peter O'Gorman]

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 &#039;~&#039; in pathnames.

*sigh* ... actually, I just don&#039;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/