Your analysis is correct. Unfortunately, libtool needs to execute multi-line
commands which may contain for loops or if statements, and so setting IFS to
';' breaks. Conceivably we could teach libtool more about parsing shell
code, but it is already far too slow for that to be a practical solution.
We chose '~' as the magic character because most shell users associate it
with home directory substitution and emacs backup files and don't use it in
the path to a project source file. Choosing another character is a feasible
solution, though you have to bear in mind that the libtool source code goes
through m4, sed and bourne shell, as well as having an autoconf pass to
subsitute configure time vars, so the quoting is hairy and sensitive to
change. Meta characters to sed, m4, autoconf or any shell that might execute
libtool are all bad choices.
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.
Cheers,
Gary.
On Thursday 14 June 2001 7:10 am, [EMAIL PROTECTED] wrote:
> Support Request #100058, was updated on 2001-Jun-13 23:10
> You can respond by visiting:
> http://savannah.gnu.org/support/?func=detailsupport&support_id=100058&group
>_id=25
>
> Category: None
> Status: Open
> Priority: 5
> Summary: 1.4 - $buildir-path may not contain "~"
>
> By: guidod
> Date: 2001-Jun-13 23:10
>
> Message:
> Logged In: YES
> user_id=614
> Browser: Mozilla/4.7 [en] (X11; U; SunOS 5.6 sun4u)
>
> 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?
>
>
>
>
> ----------------------------------------------------------------------
> You can respond by visiting:
> http://savannah.gnu.org/support/?func=detailsupport&support_id=100058&group
>_id=25
>
> _______________________________________________
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())____
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Author http://sources.redhat.com/autobook =`---d__/
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
