Re: libtool-1.5.10.ldsoinclude.patch

[Daniel Reed]

On 2004-11-17T09:13+0100, Ralf Wildenhues wrote:
) * Daniel Reed wrote on Wed, Nov 17, 2004 at 07:56:53AM CET:
) > 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?

Maybe by compiling a test program and then extracting the paths embedded in
it.

There may be no effective way to get that information for situations where
the linker runtime path changes between build time and run time, which can
be a fairly common situation when executables are built on special build
machines and then distributed to a large number of heterogeneous systems.

One possibility, if the builder (human) knows the target will be used on a
number of systems, may be to add an option to libtoolized ./configure
scripts to either specify an explicit search path culling list to use, or
just specify that the culling list should only contain /lib and /usr/lib (so
/etc/ld.so.conf's contents would be ignored even if the file exists).


Switching back to:
) > 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?

glibc-2.3.3/elf/ldconfig.c uses the following rules:
For each line:
        Strip newline.
        If there is a "#", mark the first occurrence as the end of the line.
        Skip any leading white space.
        If the line is now blank, skip it.
  (add_dir)
        If there is a "=":
                Mark the first occurrence as the end of the line.
                If what came after the "=" is not in a known subset of library 
types, error.
        Skip any trailing white space. (This now includes white space before 
the "=" if it was present.)
        Skip any trailing "/" characters unless the line is only one "/".
        If the final contents of the line do not exist as a path, error.
  (add_single_dir)
        If the current search path includes an entry with the same device and 
inode as the current path, silently stop.
        Add the path to the list of search paths.


glibc-20041116T0856/elf/ldconfig.c uses these:
For each line:
        Strip newline.
        If there is a "#", mark the first occurrence as the end of the line.
        Skip any leading white space.
        If the line is now blank, skip it.
+       If the line begins with "include" followed by whitespace:
+               Skip the "include ".
+               For each word (separated by space or Tab):
+                 (parse_conf_include)
+                       Glob the word.
+                       For each match:
+                               Recurse into the parse_conf routine with match 
as the conf file.
+       Otherwise:
          (add_dir)
                If there is a "=":
                 ...


My patch does not mimick this functionality. It does not handle multiple
glob strings per line (though it could be extended to do so by using a loop
to catenate items $2 through $NF) and it does not recursively process those
files (it just grabs their contents and injects them into the current
processing, which would skip "include" forms in the included files).

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools. -- Douglas Adams, Novelist