Re: libltdl is inefficient and a security hazard

[Howard Chu]

Bob Friesenhahn wrote:
> Doing some investigation under Linux, I see that libltdl does the same
> wrong things under Linux except that Linux employs some algorithms
> which makes doing the wrong things much less expensive than under
> Solaris.  Linux prunes directories in the search path which were found
> to not exist from later searches.  Linux also entirely ignores
> requests to load libraries which were already loaded.  However, Linux
> does still try to dlopen() a ".a" archive file.

Yeah, I recall noticing all this in the past. That's why I usually delete .la 
files after build time and make sure they never get installed. On platforms 
where the dependent shared libraries are already listed inside a shared 
library's dynamic loader section, all of this .la stuff is just wasted effort 
(and time). So far I only see .la files being useful when statically linking, 
since the .a archives don't include their dependency info. It would have been 
smarter for libtool to just store whatever it wanted to record as a stub file 
inside the .a, IMO.

Also, instead of all of that relinking cruft, should have just provided a 
libbfd-based tool that rewrites the linkage paths as needed. I've seen too 
many times where the originally built library works perfectly, but the 
relinked file that got installed is broken because the relink info didn't 
include various settings that were in the environment when the original 
library was built. Basically, relinking is doing a lousy job of 
second-guessing, and on SVR4/ELF-based platforms it's not even needed.
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/