About the dll search algorithm of dlopen

Michael Haubenwallner michael.haubenwallner@ssi-schaefer.com
Tue Aug 23 08:55:00 GMT 2016

Hi Corinna,

On 08/22/2016 08:48 PM, Corinna Vinschen wrote:
> On Aug 22 14:15, Michael Haubenwallner wrote:
>> For dlopen, it is more important to find the same dll file as would be
>> found when the exe was linked against that dll file, rather than using
>> the Linux-known algorithm and environment variables - and differ from
>> process startup: Both really should result in the same algorithm here,
>> even if that means some difference compared to Linux.
> IMHO there is no good reason to have a DLL in a 3rd party subdir which
> is available as system DLL.  DT_RPATH/DT_RUNPATH semantics are not
> created to overload system DLLs, rather to add a safe search path.  Why
> would you want to install a system DLL under the same name and thus the
> same version in a non- system dir and expect the application to load
> that?  Ultimately this is bound to becoming outdated, fail if the
> dependencies of the system DLL change, etc.

This highly depends on the definition of which DLLs are part of the
"system", and which DLLs are part of the "application".

Just installing a DLL into /usr/bin does not mean it is a "system DLL"
which an application safely can rely on.

Instead, an application expected to be "stable" has to ship dependencies
along the application itself, as it cannot expect the "system" to provide
the identical (versions of) dependencies the application was regression
tested against.

Agreed, this asks for outdated dependencies. But this is the reason why
the update mechanism of the application also is able to update its own
dependencies - within the application directory.

This allows for always running a regression tested application, which
is expected to not break just because some random DLL is installed or
updated within /usr/bin.

For the definition of "system": As the application is required to run
on lots of different operating systems and architectures, a sensible
definition of "system" that allows for most portability with least
porting effort (code duplication) is to stick with "libc", along the
lines of "POSIX" as close as possible.

> Even *if* we add the application dir adding it to dlopen should be
> configurable, not statically, invisible under the hood.

Independent of application stability and portability: Is there a reason
for dlopen to potentially find different DLLs than process startup does?


More information about the Cygwin-developers mailing list