Re: libtool-1.5.10.ldsoinclude.patch

[Ralf Wildenhues]

* Daniel Reed wrote on Wed, Nov 17, 2004 at 07:56:53AM CET:
> In Libtool 1.5.10's libtool.m4, on the Linux target, Libtool generates its
> sys_lib_dlsearch_path_spec by combining the static entries "/lib" and 
> "/usr/lib"
> with, if it exists, the file /etc/ld.so.conf's contents.
> 
> The contents of /etc/ld.so.conf are processed using a regex:
> s/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g
> 
> This should replace colons, commas, and tabs with spaces and get rid of the
> =libc5 syntax that once kept ldconfig from searching the wrong directories 
> for files (which may no longer be needed or used).

For backwards compatibility, it might still be necessary.

> A recent glibc introduced a new form for /etc/ld.so.conf: the
> "include" keyword with an argument specifying a globable path string
> relative to $(dirname /etc/ld.so.conf) of files whose contents to also
> parse as if they were included in /etc/ld.so.conf.

ACK.

> Libtool does not handle this form, and can't be extended to support it
> without changing some assumptions about the format of /etc/ld.so.conf.
> I am told that /etc/ld.so.conf's format is considered an
> implementation detail by glibc developers, and that no format will be
> guaranteed. If Libtool is to continue parsing ld.so.conf, it will have
> to be with the understanding that the file format can continue to be a
> moving target.

Begs the question: is there a more stable way to get at the information?
[1]

> Assuming Libtool will continue parsing ld.so.conf to populate
> sys_lib_dlsearch_path_spec:
> 
> The following patch causes Libtool to assume that lines in
> /etc/ld.so.conf that begin with "include " are of the special form
> "^include relative-path$", where relative-path is relative to /etc.
> The path is globbed and the contents of matching files are brought in
> as if they were part of the contents of ld.so.conf, in the location
> the "include " line is in ld.so.conf. This reformed set of directories
> is then passed through the same transformations as before.

Can the included files have `include' statements themselves?
Do we have to assume relative-path can contain white space?

> The patch introduces a call to awk; I found similar calls to awk elsewhere 
> in the code so I do not believe the patches impacts portability.

I think that is ok.  Beware however, that not all linux distributions
ship GNU awk (mawk is common as well), so we should only use the
portable subset of awk.  Your patch looks fine w.r.t. this.

> After making the change and regenerating all of the files based on
> libtool.m4, a diff generated against stock Libtool 1.5.10 is on the
> order of one hundred thousand lines. I have included only the one line
> diff; the generated files will need to be regenerated after
> application.

Please don't show patches against generated files.  Best, check out the
CVS sources and do a `cvs diff -u' for generating patches (adjusting
`diff' options is ok for me, esp for new files you might have to
special-case).

Also, libtool-1.5 is pretty much dead now, and I think it should remain
that way.  I do think it's better to apply patches if they end up in
distribution packages anyway, but as soon as 2.0 is out we should get
them to support that instead.

Other than that, ChangeLog entries are great.  For big or many changes,
a copyright assignment (or disclaimer) might be necessary.

Back to this specific change:  Anybody object if I apply it to
branch-1-5, branch-2-0 and HEAD, on the premise that there is no
satisfying answer to [1]?

Regards,
Ralf