Subject: RE: Problems creating "-mno-cygwin" DLLs with libtool HACK.
From: "Dave Korn" <[email-masked]>
To: "'Vladius'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Tue, 1 Feb 2005 18:05:53 -0000

> -----Original Message-----
> From: Vladius [mailto:[email-masked]] 

>     I have found a solution to hack this issue.
> 1.Goto usr/autotool/devel/bin/
> 2.Open "libtool" file with a text editor(vim).
> 3.Search for "postdeps" initialisation. ("postdeps=" string)
> 4.Remove "-lcygwin" initialisation literal string to the right.
> 5.Check out next variable assignment - "compiler_lib_search_path=".
> 6.change "i*86-pc-cygwin" to "i*86-pc-mingw" in all of its 
> occurences to 
> the right of varable assignment.
> 
> The resulting library created with libtool no longer depends 
> on cygwin DLL.
> 
> Does anyone have a better solution? Maybe I just missed smth allready 
> known or implemented. Please, let me know.

  I was looking through that file as well, but I see you got there first. 

  Don't forget that there's another version of libtool in
/usr/autotool/stable/bin, and that you may need to patch that one as well.
(/usr/libtool is a wrapper script that chooses the appropriate libtool version
according to the autoconf version in use).

  The fix seems ok to me, but it would be better if you could fix it so that it
only excludes -lcygwin when the -mno-cygwin flag is actually present, by testing
for it.  So maybe you want to use something a bit more like this:

--------------------------<snip!>--------------------------
--- libtool.orig	2005-02-01 17:39:45.797711300 +0000
+++ libtool	2005-02-01 17:52:42.458335100 +0000
@@ -7120,11 +7120,25 @@ predeps=""
 
 # Dependencies to place after the objects being linked to create a
 # shared library.
-postdeps="-lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32
-lgcc"
+case $compiler_flags in
+ *mno-cygwin*) # Exclude -lcygwin from mingw builds
+  postdeps="-lstdc++ -lgcc -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc"
+  ;;
+ *) # Default - assume cygwin required.
+  postdeps="-lstdc++ -lgcc -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32
-lgcc"
+  ;;
+esac
 
 # The library search path used internally by the compiler when linking
 # a shared library.
-compiler_lib_search_path="-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3
-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../.."
+case $compiler_flags in
+ *mno-cygwin*) # Don't use cygwin link libraries for mingw builds...
+  compiler_lib_search_path="-L/usr/lib/gcc-lib/i686-pc-mingw/3.3.3
-L/usr/lib/gcc-lib/i686-pc-mingw/3.3.3/../../.."
+  ;;
+ *) # Default - assume cygwin required.
+  compiler_lib_search_path="-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3
-L/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../.."
+  ;;
+esac
 
 # Method to check whether dependent libraries are shared objects.
 deplibs_check_method="file_magic ^x86 archive import|^x86 DLL"
--------------------------<snip!>--------------------------

  But note that I haven't actually tested this....

  Hmm.  I think you probably also need to change a few others in the same way as
well.  Doing a search for "-cygwin/" in the file, I found these other
definitions:

--------------------------<snip!>--------------------------
# The linker used to build libraries.
LD="/usr/i686-pc-cygwin/bin/ld.exe"
--------------------------<snip!>--------------------------

  Found that one in three places, actually, but I would guess it's
less-than-critical if we choose the wrong linker.  Might mess with default
search paths, if you were relying on them.

--------------------------<snip!>--------------------------
# Dependencies to place before the objects being linked to create a
# shared library.
predep_objects="/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/crtbegin.o"

# Dependencies to place after the objects being linked to create a
# shared library.
postdep_objects="/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/crtend.o"
--------------------------<snip!>--------------------------

  These two are just before the section I quoted above, and it seems almost
certain to me (again, without having tried or tested it) that if you want a
mingw compilation, you should be using the mingw runtime startup and termination
modules.  So the same sort of case statement as I used above would work again.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/