libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cygwin/mingw: do not lie about hardcoding


From: Eric Blake
Subject: Re: cygwin/mingw: do not lie about hardcoding
Date: Wed, 06 Sep 2006 06:07:54 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ralf,

According to Ralf Wildenhues on 9/5/2006 11:46 PM:
> This is a new TODO item.
> 
> The w32 support in Libtool currently lies about their hardcoding
> capabilities by setting hardcode_libdir_flag_spec to a nonempty value.
> This makes ltmain think that it can hardcode this way.
> 
> More generally, the search order is:
> 
> - the directory of the current executable,
> - the current directory,
> - the w32 system directory (GetSystemDirectory returns this),
> - the w32 directory (GetWindowsDirectory returns this),
> - directories in PATH.

But that is the search order for native windows .dlls and LoadModule.
Cygwin dlopen(), on the other hand, strives for Linux compatibility, and
has tricks up its sleeve to override the Windows default search path with
one that is more similar to Linux shared library lookup.  So I'm not sure
whether this TODO is mingw only, instead of cygwin/mingw.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE/roa84KuGfSFAYARAhpLAKC28Fc3R4nNd73D3pFD0+pFhZMdwQCeIdf0
b/6Dvystw28Y5ZlvyDF/45o=
=4vl0
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]