Re: cygwin/mingw: do not lie about hardcoding
-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 [EMAIL PROTECTED] -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-
Re: cygwin/mingw: do not lie about hardcoding
On Wed, 6 Sep 2006, Eric Blake wrote: 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. Are you saying that Cygwin supports LD_LIBRARY_PATH? Cygwin programs are obviously originally located using Cygwin-supplied rules (due to the Unix-style shell). Does Cygwin also handle locating/loading all of the DLLs that the application depends on? Doing so would require special static startup (crt) code for Cygwin applications which knows how to evaluate dependencies and load DLLs since otherwise normal Windows rules would apply. My understanding is that most (all?) Cygwin code resides in a single DLL. The fact that Cygwin installs DLLs in the executable 'bin' directories strongly suggests that there is no special startup code and that Windows handles the DLL loading using its own rules. Lastly, does libtool now use Cygwin's dlopen()? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Supporting -export-dynamic on AIX
On Tue, Aug 08, 2006 at 02:58:44PM -0500, Albert Chin wrote:
Another version. Patch against branch-1-5 only. I've reordered where
--export-dynamic occurs so we don't have to worry about the above.
Our use of both $export_dynamic_symbols_cmds and
$export_dynamic_flag_spec somewhat breaks the whether a program can
dlopen itself test:
case $lt_cv_dlopen in
dlopen)
save_CPPFLAGS=$CPPFLAGS
test x$ac_cv_header_dlfcn_h = xyes CPPFLAGS=$CPPFLAGS -DHAVE_DLFCN_H
save_LDFLAGS=$LDFLAGS
wl=$lt_prog_compiler_wl eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\
...
Why? Because we set $export_dynamic_flag_spec to:
_LT_AC_TAGVAR(export_dynamic_flag_spec,
$1)=\${wl}$exp_sym_flag:\$export_symbols
so, in the above LDFLAGS=$LDFLAGS -Wl,-bexport:. Because -bexport:
requires an argument, we get an error from the linker:
ld: 0706-015 The -b export option needs a parameter.
Option syntax: -b export:PARM
We could make this test pass by creating conftest.exp, setting
export_symbols=conftest.exp, and adding fnord to it:
save_LDFLAGS=$LDFLAGS
echo fnord conftest.exp
wl=$lt_prog_compiler_wl export_symbols=conftest.exp \
eval LDFLAGS=\\$LDFLAGS $export_dynamic_flag_spec\
Should we do this or let it continue failing?
--
albert chin ([EMAIL PROTECTED])
