Re: Spaces in pathnames: forbidden, supported or not tested ?
Hi Ralf, Thanks for your answer. I have followed your advice to *not* install neither MinGW nor Msys in a path containing spaces (and everything went well). However, this is not a long term answer, as it seems to me difficult to state that autotools forbid the use of paths with spaces. The solution I had behind my head (which is somewhat different from yours) would be to write a small program (call it eval_progname) which interface is similar to 'time', namely that takes a progname and a list of arguments usually passed to the shell for evaluation and execution. 'eval_progname' will take its first argument (which will be the "$LD" for example, quotes are important here) and try to find the location of the first space which preceeding path would lead to a valid executable (with the help of PATH environment variable for relative paths); then it will restore the actual progname as the actual one to be executed, and the rest of the first argument as actual arguments preceeding the original arguments. It finally will 'exec' the computed progname with computed arguments. Of course, such a program could be escaped with "eval" for people who knows that there is no space in their paths (and for evaluation without 'eval_progname'), and it should not break any backward compatibility in the rest of autotools code. I guess that it could also be written as a shell function, but I think that an executable should be much more efficient. IMHO, this should bring a solution to the problem of execution, but not for variable evaluation. But I guess that autotools already should handle carefully spaces in variable evaluation, and if they don't, then they should be fixed directly. Your comments are welcome, as I intend to validate that this solution works for autotools (this is rather easy with a Windows system and MinGW). Thanks for your comments, Eric Ralf Wildenhues wrote: Hi Eric, * Eric PAIRE wrote on Mon, Aug 29, 2005 at 03:31:06PM CEST: I am currently using 'configure' generated file under MinGW. On Windows, Msys and MinGW have been installed in 'Program Files' (Yes, there is an *snip* The 'gcc -print-prog-name-ld' command in AC_PROG_LD returns a complete Windows path which contains a space, then the execution of $LD in AC_PROG_LD_GNU fails, and my LD is not detected as a GNU ld, which has some unwanted consequences... I can imagine.. *snip* I would like to get your comments on that, and particularly if paths with spaces in them are supported, or if it is not tested, or if this should be forbidden. In the later case, I guess that this should be clearly stated somewhere (and if it is, I have not been able to find it, sorry). I can give you an unofficial statement: It's a mess. It might work in some cases, but in most it'll break eventually. Autotools started thinking about path names with spaces only very much in an afterthought, long after they were established. One reason is because on classic unixy systems, they are very rarely used. Another is the very common use of white space as command line separator by the common unix shells. Recently, a patch has been posted to make Libtool be able to use spaces in their path names in many places (not the one you're seeing, I believe). I hated the fact that I had to reject it because it breaks compatibility. I've been thinking ever since how we could introduce spaces in variables which contain file lists. In fact, I'm still convinced that it *can* be made to work. It's just a huge amount of work to do it right, and pretty tricky at times[1]. If anyone wants to work on this for Libtool-3.0 (sic), I'm happy to discuss possible plans that would not break compatibility with every other version and autotool we have. For now, though, it's by far easier if you did not use paths with spaces, or some sort of symlinking mechanism to work around them. Cheers, and sorry, Ralf [1] one trick would be to use TAB as list separator and juggle with IFS .. would make for *really* unreadable code.. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...: While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be "good enough", I think, unless someone comes up with an easy way to guard against the issue. How about this? [patch elided] I think it's commit-worthy. It certainly helps outline the issue, and points to a source for more information for the people it impacts. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Spaces in pathnames: forbidden, supported or not tested ?
Hi Eric, * Eric PAIRE wrote on Mon, Aug 29, 2005 at 03:31:06PM CEST: > > I am currently using 'configure' generated file under MinGW. On Windows, > Msys and MinGW have been installed in 'Program Files' (Yes, there is an *snip* > The 'gcc -print-prog-name-ld' command in AC_PROG_LD returns a complete > Windows path which contains a space, then the execution of $LD in > AC_PROG_LD_GNU fails, and my LD is not detected as a GNU ld, which has > some unwanted consequences... I can imagine.. *snip* > I would like to get your > comments on that, and particularly if paths with spaces in them are > supported, or if it is not tested, or if this should be forbidden. In > the later case, I guess that this should be clearly stated somewhere > (and if it is, I have not been able to find it, sorry). I can give you an unofficial statement: It's a mess. It might work in some cases, but in most it'll break eventually. Autotools started thinking about path names with spaces only very much in an afterthought, long after they were established. One reason is because on classic unixy systems, they are very rarely used. Another is the very common use of white space as command line separator by the common unix shells. Recently, a patch has been posted to make Libtool be able to use spaces in their path names in many places (not the one you're seeing, I believe). I hated the fact that I had to reject it because it breaks compatibility. I've been thinking ever since how we could introduce spaces in variables which contain file lists. In fact, I'm still convinced that it *can* be made to work. It's just a huge amount of work to do it right, and pretty tricky at times[1]. If anyone wants to work on this for Libtool-3.0 (sic), I'm happy to discuss possible plans that would not break compatibility with every other version and autotool we have. For now, though, it's by far easier if you did not use paths with spaces, or some sort of symlinking mechanism to work around them. Cheers, and sorry, Ralf [1] one trick would be to use TAB as list separator and juggle with IFS .. would make for *really* unreadable code.. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 -static and installed libraries
On Mon, Aug 29, 2005 at 03:34:17AM -0700, Howard Chu wrote: > Ralf Wildenhues wrote: > >Should we discuss this and decide about what's best? Maybe we'd need > >another switch to link statically against all non-system libs (in the > >sense that libc is one, but libdb is not)? Or would implementing per- > >deplib static/shared switches be the only solution? > > That may work best, though it sounds tedious. A lot of linkers allow > -static/-dynamic to be specified multiple times on a command line, > toggling the choice until the next switch occurs in the options. Yeah, I think this is really the only sane way. Multiple static flags is too hard. Unfortunately, -static and -all-static are taken. From ld(1) on Redhat: -Bstatic -dn -non_shared -static Do not link against shared libraries. This is only meaningful on platforms for which shared libraries are supported. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
On Mon, 29 Aug 2005, Ralf Wildenhues wrote: Regardless, LTDL_INIT is not documented at the moment, and I'm not sure we want to explicitly support use of libltdl except as a subpackage. Although it has been possible to do so for quite some time (if only because libtool itself has done so on and off over the last few years), we have never really *designed* an interface for it. Post-2.0, we can always firm up a long term interface, document it and *then* make a commitment to support that interface in the future. I don't understand this paragraph at all. From what I could gather, this was one of *the* new features to be advertised for the next stable version. When Bob reported several times that it was nonfunctional, never was there a reply of yours stating this wasn't intended feature. Yes, it was intended to be one of the main new features of libtool 2.0. If it is not documented now, then someone has deleted some documentation since there was certainly some (poor) documentation added to describe it after Gary did the work in February 2003 and announced it to the world. Unfortunately, the work was not yet to a finished/tested state. The plan is that packages using libltdl 2.0 can configure libltdl using their own configure script. This reduces configure run time by about a factor of two and also reduces the amount of configure script code by a factor of two. Reducing configuration time by a factor of two is a huge win. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Spaces in pathnames: forbidden, supported or not tested ?
Hi, I am currently using 'configure' generated file under MinGW. On Windows, Msys and MinGW have been installed in 'Program Files' (Yes, there is an unfortunate space in it), and most of the installed packages configure properly (probably by chance, because I do use tools installed in standard and not specified by environment variable), except for LD, because LD is positionned by the AC_PROG_LD macro, which calls AC_PROG_LD_GNU macro. The 'gcc -print-prog-name-ld' command in AC_PROG_LD returns a complete Windows path which contains a space, then the execution of $LD in AC_PROG_LD_GNU fails, and my LD is not detected as a GNU ld, which has some unwanted consequences... It seems to me that nothing prevents path names to get spaces in them, but the problem is that using `"$LD" -v` requires that LD does not contain some particular argument put with the pathname of ld. This solution might work if LD arguments are not added to LD, but to another FLAGS argument specific to LD (and probably not to LDFLAGS) that differentiates the progname from its arguments. I would like to get your comments on that, and particularly if paths with spaces in them are supported, or if it is not tested, or if this should be forbidden. In the later case, I guess that this should be clearly stated somewhere (and if it is, I have not been able to find it, sorry). Thanks, Eric ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: branch-2-0 vs CVS HEAD
Hallo Ralf,
On 29 Aug 2005, at 12:43, Ralf Wildenhues wrote:
Hi Gary,
private mail on purpose?
Nup, my MUA is playing silly buggers. :-( Might go back to webmail
until
I've had chance to configure Thunderbird the way it's behaving atm! Grr.
[Quoting everything for the sake of readers on the list.]
* Gary V. Vaughan wrote on Mon, Aug 29, 2005 at 12:38:50PM CEST:
On 29 Aug 2005, at 07:29, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Sun, Aug 28, 2005 at 11:56:31PM CEST:
Regardless, LTDL_INIT is not documented at the moment, and I'm not
sure we want to explicitly support use of libltdl except as a
subpackage. Although it has been possible to do so for quite some
time (if only because libtool itself has done so on and off
over the
last few years), we have never really *designed* an interface
for it.
Post-2.0, we can always firm up a long term interface, document it
and
*then* make a commitment to support that interface in the future.
> > >
I don't understand this paragraph at all. From what I could gather,
this was one of *the* new features to be advertised for the next
stable
version.
If I have touted this as a feature, I've forgotten. Mea culpa.
Actually, I don't /know/ whether you did that, or I just always
understood wrongly. At least it seems Bob misunderstood then, too.
Good point.
When Bob reported several times that it was nonfunctional,
never was there a reply of yours stating this wasn't intended
feature.
It certainly ought to work, because libtool itself is using it.
Libtool is not using LT_WITH_LTDL in $top_srcdir/configure.ac.
But client packages need to have the additional configure switches and
logic which is only triggered by LT_WITH_LTDL.
If OTOH you add LT_WITH_LTDL to configure.ac, at least the
AC_CONFIG_SUBDIRS at its end breaks libltdl-as-non-subpackage.
Was this bug description halfway understandable?
Yep. Thanks.
While I can see you backing up because you want to move closer to
this
release, I cannot understand how you can argue now that this was
not a
feature users should be able to profit from.
I am backing up because I want to release 2.0 asap. On reflection, I
can't see any problem with supporting the current API for the
forseeable future. I'll work on a doc patch today.
Please keep the above in mind. It would be very cool if this could be
made to work.
Sure.
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
RE: config.status (or something) writes out a crippled libtool script
Ralf Wildenhues wrote: > > > > 10. make > > > [ triggers ltmain.m4sh -> ltmain.sh recreation ] > > > > /bin/sh: autom4te: command not found > > > *snip* > > > > > > Thanks for this report. Can you try the attached patch? > It has the > > > > Seems to work nicely. Thanks! > > Yet it's the wrong fix. Again. > Last time it needed Alexandre to remind us: No system-specifics may end > up in ltmain.sh! Why? It's used by clients when they libtoolize. There seems to indeed be something missing, but I don't know if the following is what you are referring to, so I'm just doing this report on the odd chance that it isn't... It (crippled libtool script) still happens from time to time. I *think* it happens when I do a change to e.g. libtool.m4 and then forget to bootstrap and just run configure in MSYS (where I don't have autotools). After that, I get a borken libtool script. Simply trying to bootstrap (in Cygwin) after such a mistake does not help, but thanks to your patch I have figured out that touching libltdl/config/ltmain.m4sh followed by bootstrap does the trick. Cheers, Peter ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: argz.m4 showstopper?
Hallo Ralf,
On 29 Aug 2005, at 07:43, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Mon, Aug 29, 2005 at 01:47:54AM CEST:
Currently http://tkd.kicks-ass.net/GnuLibtoolProject/Roadmap says:
Does the client need argz.m4? Only if libtoolize --ltdl?
Is this just that argz.m4 is always added to a client by libtoolize,
but sometimes might not be needed?
Well, it's needed exactly when ltdl.m4 is needed.
If so, I move to strike it as a showstopper, and worry about it
post-2.0.
Shouldn't this be very easy to fix?
Oh, no doubt. It's not a showstopper for the release though!
Cheers,
Gary.
--
Gary V. Vaughan ())_. gary@
{lilith.warpmail.net,gnu.org},[EMAIL PROTECTED]
Research Scientist ( '/ http://www.tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/{libtool,m4}
Technical Author `(_~)_ http://sources.redhat.com/autobook
PGP.sig
Description: This is a digitally signed message part
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 -static and installed libraries
Ralf Wildenhues wrote: Hi Howard, Alexandre, others, * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST: We just migrated from libtool-1.4.3 to 1.5.18 in the OpenLDAP CVS HEAD, and are seeing a new linking problem. You've migrated *already*? :-) This was actually our 2nd or 3rd attempt. Now that we've gotten off of autoconf 2.13.1 we may be able to move a little faster from now on. ;) (Hey, Cyrus SASL still ships with libtool 1.3.5...) So the question is, why does linking with -static cause libtool to behave like -all-static was used, why does it ignore the installed status of the libraries? (You also sent a patch to change this behavior to match the current, i.e., both branch-1-5 and CVS HEAD, documentation). Now while your patch looks ok at a glance, I'm unsure whether what is wanted by users is what the documentation says or what the current code does. See for example this discussion between Akim and Alexandre about the issue: http://lists.gnu.org/archive/html/libtool/2005-01/msg00350.html Yes, I read through that discussion but it seemed to be a fairly special case. It didn't make any sense to me, really - requesting a static link, while requesting that no static libraries be built... Something I didn't test properly yet is what happens if the executable needs to be relinked at install time. Since the just-built libraries will most likely be installed before the exe is relinked, it seems to me it may foul up. (But my SuSE system didn't need relinking; will have to try again on a different platform to see.) Should we discuss this and decide about what's best? Maybe we'd need another switch to link statically against all non-system libs (in the sense that libc is one, but libdb is not)? Or would implementing per- deplib static/shared switches be the only solution? That may work best, though it sounds tedious. A lot of linkers allow -static/-dynamic to be specified multiple times on a command line, toggling the choice until the next switch occurs in the options. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5 -static and installed libraries
Hi Howard, Alexandre, others, * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST: > We just migrated from libtool-1.4.3 to 1.5.18 in the OpenLDAP CVS HEAD, > and are seeing a new linking problem. You've migrated *already*? :-) > By default we link with -static so > that our local libtool-generated libraries get statically linked. But we > don't use -all-static; we don't want to alter the default linking for > system-installed libraries. OK. > On SuSE 9.x when the libdb devel RPM is installed, a libdb.la file is > also installed, and libtool 1.5 finds and reads this file. In this case, > libtool chooses to link the static libdb into our slapd executable, > rather than the shared library, even though the .la file says > "installed=yes". This results in an unusable binary on SuSE 9.x because > the default static library doesn't support thread-local storage/NPTL, > while the default C library requires it. (But if the shared library is > used instead, the runtime linker can locate the correct libdb.) OK. Sounds like a reasonable setup. > So the question is, why does linking with -static cause libtool to > behave like -all-static was used, why does it ignore the installed > status of the libraries? (You also sent a patch to change this behavior to match the current, i.e., both branch-1-5 and CVS HEAD, documentation). Now while your patch looks ok at a glance, I'm unsure whether what is wanted by users is what the documentation says or what the current code does. See for example this discussion between Akim and Alexandre about the issue: http://lists.gnu.org/archive/html/libtool/2005-01/msg00350.html Should we discuss this and decide about what's best? Maybe we'd need another switch to link statically against all non-system libs (in the sense that libc is one, but libdb is not)? Or would implementing per- deplib static/shared switches be the only solution? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
