Re: libtool--gary--1.0--patch-36

[Peter O'Gorman]

Gary V. Vaughan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Okay to commit?

A couple of typo's and a question or two, so not quite yet.

> Index: Changelog
> from  Gary V. Vaughan  <address@hidden>
>
>         The Grand Renaming.  In preparation for libtool-2.0, move all of
[]
> 2004-08-06  Gary V. Vaughan  <address@hidden>
>
>         * libltdl/ltdl.c (lt_dlforeachfile): LT_SYS_LIBSEARCH_PATH is not
>         an environment variable, it is an actual path.
>         Reported by Noah Mish <address@hidden>

So there are two separate patches in here?

> address@hidden LT_CMD_MAX_LEN
> +Finds the longest command line that can be safely passed to
> address@hidden without being truncated, and store in the shell variable
> address@hidden  It is only approximate an approximate value, but

I think you only want the second approximate.


> +Macros in the @samp{LT_FUNC_} namespace check characteristics of
> +librory functions:

I think you'll notice the librory in there... library :)


> address@hidden LT_SYS_SYMBOL_USCORE
> +Set the shell variable @samp{sys_symbol_underscore} to @samp{no}
> +unless the compiler prefixes global symbols with an underscore.
> address@hidden defmac

Maybe add a note that this is not the same thing as testing if dlsym 
requries an underscore. At least on darwin these are different. There is an 
underscore in symbol names, but dlsym does not need one.


>  }.  Having made the macros available, you must add a call to the
> address@hidden macro to your package's @file{configure.ac} to
> address@hidden macro to your package's @file{configure.ac} to
>  perform the configure time checks required to build the library
>  correctly.  This method has problems if you then try to link the
>  package binaries with an installed libltdl, or a library which depends
>  on libltdl: you will have problems with duplicate symbol definitions.

All of this makes me wonder. We are not planning on providing developers 
with some compatibility for their existing configure.ac scripts? Is it not 
possible to accept both the old and new names for the first 2.0 release and 
warn that the old names are deprecated (of course I mean only for the 
"public" API in current stable libtool).

Anyway, haven't gotten to read most of this patch yet. But I'll send this as is.

Peter
--
Peter O'Gorman - http://www.pogma.com