Re: Re: libbfd, libtool Win32 and Re: Building a MinGW GLibetc...
Guido writes: Aren't these two interrelated? I thought that the relink step was done to try to ensure the libs have a different image-base, even though it might never been implemented that way... Umm, never thought of that. I thought that the relink was done because of some issues with search paths, or full paths to shared libraries, stored in executables (and shared libraries) on some platforms. And, as Win32 exes and dlls only have DLL basenames in them, thus irrelevant. (Even if the relink step was done to set a hopefully unique image base, why couldn't that be done when linking the first time?) --tml ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Re: libbfd, libtool Win32 and Re: Building a MinGW GLibetc...
Guido Draheim wrote: (A) the sys_lib_search_path spec gets hardcoded to the cygwin path. no go on mingw cross. $CC -print-search-dirs rules. I wish I knew why this hack is required on Cygwin (B) final $dlname to ../bin/$dlname - interesting way to do about this but probably interfering with autoconfed installpath specs (I for one use an ac-macro to make the default of $libdir the same as $bindir which has the effect of what's needed - to bring the dlls into $PATH). I agree that this is inelegant. Ideally, we would calculate the relative path to bindir from libdir, but I don't know how to do that. Anyone? (C) what's that install-number-increment-sedscript about? The give-dlls-execute-permissions-sedscript? Because on Cygwin with ntsec, the dll is installed without execute permission, so cannot be used. (D) is that a shellscript to make a .def file and compile it? cute... but let's see if it works cross. No idea - I just copied and pasted from the existing code in libtool.m4. Max. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
