Hi Peter, Not meaning to seem overly pedantic, but could you enumerate the release(s) you tested when you decided that it was safe to close this?
Also, it seems like it would a good item to put into TODO (when you summarise the hideous TODO thread) that we should add a regression test to the new testsuite for this condition. Cheers, Gary. Peter O'Gorman wrote: > This mail is an automated notification from the support tracker > of the project: GNU Libtool. > > /**************************************************************************/ > [support #100058] Latest Modifications: > > Changes by: > Peter O'Gorman <[EMAIL PROTECTED]> > 'Date: > Wed 11/24/2004 at 13:42 (Japan) > > What | Removed | Added > --------------------------------------------------------------------------- > Resolution | None | Done > Assigned to | None | pogma > Status | Open | Closed > > > ------------------ Additional Follow-up Comments ---------------------------- > I am pretty sure that this is fixed in libtool-1.5.2 and later. > > Closing. > > > > > > > /**************************************************************************/ > [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 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 '~' in pathnames. > > > *sigh* ... actually, I just don'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/ > > > > > > _______________________________________________ > Libtool mailing list > [EMAIL PROTECTED] > http://lists.gnu.org/mailman/listinfo/libtool -- Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org} Research Scientist ( '/ http://tkd.kicks-ass.net GNU Hacker / )= http://www.gnu.org/software/libtool Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool