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])
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: cygwin/mingw: do not lie about hardcoding
Hello Eric, * Eric Blake wrote on Wed, Sep 06, 2006 at 02:07:54PM CEST: > According to Ralf Wildenhues on 9/5/2006 11:46 PM: > > > > The w32 support in Libtool currently lies about their hardcoding > > capabilities by setting hardcode_libdir_flag_spec to a nonempty value. > > More generally, the search order is: *snip* > But that is the search order for native windows .dlls and LoadModule. True. I assumed so far that would hold for all w32 platforms. > 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. So, then the question is where is the Cygwin semantics documented (for both the link editor's behavior, as well as the runtime linker's) and does it have a form of hardcoding as well? And if yes, why are we not using it? Thanks, Ralf
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-