Re: [ 100058 ] 1.4 - $buildir-path may not contain "~"

[Gary V . Vaughan]

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, address@hidden 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
> address@hidden
> 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__/