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

[Guido Draheim]

> 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 wonder 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 "~".

OTOH,
   the link to the usage of "~" for homedirs is just valid
   for the first letter, and shells will only expand those.
   I ask myself if it wouldn't have been possible to use a
   delimiter-char of the shell-tokenizer - no user will
   be tempted to use such a char, e.g. "&" and "|", and
   often "!". (I rememeber a problem where a "#" was used
   as in *most* areas a name like a#1 will *not* have a 
   tokenizer break at the #, but *sometimes* it did happen).

   Using a shellspecial-char just imposes a restriction on 
   the complexity of the actual scripts stored as a 
   singleline-string in the libtool-shellvars. Perhaps this
   is easier to maintain than finding the current instance
   where the absolute-path-resolution and IFS="~" handling
   just don't come to a satisfying result.

cheers, Guido


"Gary V. Vaughan" wrote:
> 
> 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__/
> 
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool

-- guido                         Edel sei der Mensch, hilfreich und gut
31:GCS/E/S/P C++$++++ ULHS L++w- N++@  d(+-) s+a- h.r(*@)>+++ y++ 5++X-