[Top][All Lists]

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

Re: crossmingw32

From: Guido Draheim
Subject: Re: crossmingw32
Date: Tue, 25 Dec 2001 20:10:45 +0100

Es schrieb Rodrigo Augusto Barbato Ferreira:
> Hi,
> I am not succeding in generating .dll libraries using
> autoconf-2.13/automake-1.4/libtool-1.3.5 in a crossmingw32
> environment over my gnu/linux box.
> I believe it is a bit diferent than building in a
> mingw32 or cygwin environment over a windows box
> ([un]fortunately I do not own windows to do that).
> I hope someone here could point me some simple directions
> in how to do that, so that I can see what I am missing.

Guido Draheim wrote on Aug 2, 2001:
> Mumit Khan wrote:
> > Excellent! Thanks for putting this together. I'll put it on Mingw web site
> > with your permission (when I return from vacation in about 1.5 weeks).
> > 
> your welcome. I did intend to make up a small series of documents 
> circulating around portability of sharedlib creation, to be put
> into a dedicated area of its own (on my homepage?) - it just happens 
> that I have not much time, so it boiled down to the most pressing
> of Q/A docs being about creation of dlls with libtool and crossgcc .
> Anyway I'll attach a html'ized version of the faq that I did make 
> up just yesterday. Feel free to correct me (atleast I should put
> a pointer a section about life AFAICS).

... I have that "dllmaker guide" up in my head but no time to write
it down - AFAICS it would be about 60 pages and no one will pay me
for that....

anyway, hope this old "crossgcc mingw32 dll FAQ" can be of some help.

cheers guido

crossgcc mingw32 dll FAQ

Do you have another Q/A that could go into an FAQ? Do you know another webpage already with some (same|other) explanation? Then write today, either to the mailinglist (libtool(@) or the orignal author.

(this document was written by Guido Draheim <guidod(at)> using the copyright legalese of the GNU FDL, where reproduction restrictions do not apply when put inside other documentation describing gcc+win32 target for programs (the main topic of this))


Q: can I use libtool 1.3.x to build dlls?
A: Theoretically yes, practically no. Using libtool-1.4 is a far
   better choice, or use the patched version you can find in the
   SDL tarball living at In any case, for 
   either 1.3.5 or 1.4 (but not the sdl-patched 1.3.x): 

               DO NEVER FORGET TO SET "-no-undefined"

   as a linker flag, libtool won't do it automatically just for being
   needed in enable-shared mode. (Libtool can create about any win32
   static-libs even with undefined_allowed, but it would not do so
   with -no-undefined plus failures in creating the dll just before.)
   Since you are already doing a [case "$host_os" in mingw*) _FLAGS=xx]
   in your, then you can go and have a look at some
   other useful options for win32/dll creation.
   -no-inhibit-exec ... but rarely with an effect, instead it may
              obscure some bugs during compiling. But it is sometimes
              helpful while deep in the development stage of your project.
   -mconsole or -mwindows ... links with different startup code,
              the latter assumes your code opens a GUI window on its own
              and likes to be run detached from console. Real windows
              developers even know about threaded libc, differences
              about dos-box/nt-box, stdout/stderr handling for GUI-apps,
              and quickwin options to have console unfold its own 
              window even when started on console - be lucky to have
              just the choice between two -m/machine options.
   --export-all-symbols ... a dlltool option, ignoring hints from
              gcc given via in-source __attribute__(dllexport) marks.
              There are other options, especially about export-lists
              from your handcrafted def-file, or regex-definition
              on symbols. But usually you just use this one.
   -export-dynamic ... the libtool option you would normally use
              to export functions - just as there are other defintions
              including regex-variants.
   -avoid-version ... a libtool option - since 1.4 the generated dll
              file be named as if for a unixish system - where it
              would be on system, it is now
              libmylib-2-5-8.dll for win32 compiling. This is roughneck
              style towards win32 naming scheme - remember that windows
              does not support symlinks, and therefore windows-dllloader 
              will never see files like libmylib.dll or libmylib2.dll
              or libmylib25.dll - they are simply not existant. Unless
              it is a private-lib, you want to do something about it, e.g. :
    -release ... a libtool option - on unix systems you would simply
              use "-release $VERSION" unless you care about the
              interface-age that you could tell via "-version-info".
              you might want to make it settable from where
              you can just delete the patch-level from the version-spec.
    -module  ... another libtool option that will make it to *not* put 
              the "lib"-prefix up front of your dll-name. However I do
              not recommend to use it - it makes compiling with unixish
              tools (including libtool) a lot more problematic, so just
              leave it and make everyone know that this dll is originally
              a unixish one. Use -module only for real dll-modules that
              are private to your app and imported via LoadLibrary.

   If you feel this is complicated then you have not seen the
   additional Makefile-rules and dlltool checks that were needed
   just a few years back. Be lucky that libtool is intelligent
   enough to make the needed dlltool calls on its own, and that
   you just need to guide it into better directions with a
   few additional commandline options that nicely fit into
   automake's  _LIBADD, _LDFLAGS makevars.

>Q: where can I get a nice mingw32 crosscompiler
A: RedHat has commercial offers for about any crosscompiler you
   want to have, and they possibly have a cygwin one prepackaged for free.
   There are a lot of infos how to compile a set of gcc/binutils but
   they are often outdated just as their prepackaged tools are - they
   have been in use by just one person alone, and they posted their
   tools to the net for reusage. After they got no feedback, the webpages
   withered. The current best source for a linux-based mingw32 crosscompiler 
   lives at - this compiler is in frequent
   use for multiple dozen projects, so it has most of the initial 
   compile bugs cleaned out. It has correct gcc, binutils and windows-headers
   and offers also prebuilt cross-packages for commonly used libs

Q: what about the debian mingw32 crosscompiler? what about address@hidden
A: in 2000, some debian developers started a project to port a decent set 
   of unixish tools to windows, most of the based on GPL cygwin environment.
   Right there you will also find a good mingw32 crosscompiler package
   in the unstable/testing section of the debian repository that you can
   use. There had been plans (and still are) to add a windows platform
   (cygwin, mingw, pw32) for the automatic test building of debian
   systems - the release of address@hidden for free use will further efforts
   in that direction in the next time. This is no social effort from, it is meant so that kde-based apps (like kde itself is 
   now) will more and more detach itself from X11 which renders them at 
   the same time to be compilable on top of embedded-Qt and handheld-OS. 
   Anyway, this move (just a few weeks old at the time of writing) will 
   involve more people into the process of cross-compiling to windows 
   targets, thereby using libtool's functionality about it.
   (btw, debian's target is i586-mingw32msvc which according to the 
    packager makes sense because the target OS do not run on i386).

Q: I'm getting a libtool message saying
   *** Warning: This library needs some functionality provided by XXX.
   *** I have the capability to make that library automatically link in when
   *** you link to this library.  But I can only do this if you have a
   *** shared version of the library, which you do not appear to have.
   what's wrong? 
A: current libtool has this message in six (!!) different places, so
   that there are six different answer to what's wrong. In general your
   linker line contains a "-lxxx" statement, and libtool was trying one
   of the six ways to handle it. Which method it did invoke is not
   visible, and there are mostly no further diagnostics. This FAQ
   can not help you either before libtool maintainers make the six
   messages screens simply different.

   for the rest of this faq, let's call the message screen "dunno-yo-lib"

Q: I get the "dunno-yo-lib" message screen but I do know that I have the 
   lib as it is installed in ..../cross-tools/.../i386-mingw../lib. 
A: libtool wants to find the real lib-file before running the actual
   linker (dlltool friends). However there is a bug in the libtool.m4
   about the setting of sys_lib_search_path_spec being only correct
   for native-compiling (it has a $PATH_SEPARATOR ";" hardcoded). 

   Fix it by using a patched libtool.m4, 
   and a quick fix is to hardcode the path_spec.

Q: I try to link to a dll living in another subdirectory than the
   local target, the output screen says
       extracting exported symbol list from `libpfe-0-31-57.dll'
       [some text looking like monkey typing]
      ./libtool: .libs/impgen: cannot execute binary file 
A: libtool needs an import-lib to resolve dependencies with the
   dll living in another's .libs-builddir. It tries to make one
   on the fly but binutils does not bring a dlltool with the
   required functionality. The monkey-typing is actually an effort
   to create an executable that can build extract a def-file that
   holds the exported-symbols-list from the dll that it had found.
   This exported-symbols-list-extractor is called "impgen", and
   the sourcecode impgen.c is shipped as part of your libtool. 
   The libtool has now created this impgen.c on the fly, and it
   did call a C compiler to compile it - but since you used a
   cross-compiler, the resulting executable is a win32-exe, and
   when called your operating system says "cannot execute binary file".

   quick fix: you need to set an AC_SUBST(HOST_CC) in your Makefile via, and have that HOST_CC different from the current CC,
   there are possible ac-macros you can use, or try one yourself.

   debug fix: go the relevant .libs directory, remove about everything
   including "impgen", `cc impgen.c -o impgen ; ln -s impgen impgen.exe`

Q: I try to link to a dll living in another subdirectory, just as
   above, I have done everything correct, including the required -L,
   but I get a long set of "unresolved symbols" where I know that
   my other lib has them. 
A: You have missed the impgen-message from above - the current
   impgen-hack uses a shell-redirection to create the def-file
   that contains the exported-symbols. If it can not execute then
   the def-file is still created but it is empty. The rest of the
   steps will continue, creating a nice libimpmylib that contains
   nothing but glue and no symbols at all.

   quick fix: you need to fix the impgen-crossgcc-bug as described
   above, go to your local ".libs"-builddir, and remove imp-defs
   like `rm libimp* ; rem *-def` so that the import-libs are going 
   to get rebuild on next linker-call

Q: everything is resolved but a data-symbol from my dll, is there
   another dllexport needed or what? 
A: Theoretically you can both export and import data-symbols
   via dlls too, but practically you don't want to. Avoid it
   like hell. If you need to reference a data-table from another
   dll into something else, start adding a function-wrapper
   into your sources. That is
        _export data_entry datatable[] = { .... };
        extern data_entry datatable[];

         _export data_entry* datatable () {
               static data_entry _datatable[] = { .... }
               return _datatable;
         extern data_entry* datatable ();
         callwith (datatable());

   In fact, if you declare an export-def for a data-symbol,
   the import-def needs to be declared as a pointer to it.
   The windows-loader will not patch your code section
   [ at "callwith(datatable)" the argument-push for the
     function-call is in the code-segment, and the address
     of datatable would be needed to be patched in]
   instead it has an import-table for you that it can
   fill with the address of the datatable in that other dll.
   [ you would ask for "callwith(*datatable)" where the
     datatable is a symbol (of simple pointer type) in the 
     import-section of your executable that gets filled 
     with the datatable-address of the (other, same-named)
    symbol in the dll (which is a real field in the example) ]

reply via email to

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