> 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, [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
-- 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-
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
