GNOME Bugzilla – Bug 561340
Problem with MSYS and MINGW: undefined reference to _imp__xmlFree
Last modified: 2009-11-03 21:24:14 UTC
Please describe the problem: Hi, if found a problem when using the libxml library to build opensync on Windows with MSYS and MINGW. I get errors described below. I found some email thread from 2004 which describes the same problem. I changed the xmlexports.h include file and then I can compile. (See the #if 0 part). I do not know too enought about building the library, so I cannot provide a full patch. ===== Extract from modified xmlexports.h file ========== #if defined(_WIN32) && defined(__MINGW32__) #undef XMLPUBFUN #undef XMLPUBVAR #undef XMLCALL #undef XMLCDECL #if 0 #if defined(IN_LIBXML) && !defined(LIBXML_STATIC) #define XMLPUBFUN __declspec(dllexport) #define XMLPUBVAR __declspec(dllexport) #else #define XMLPUBFUN #if !defined(LIBXML_STATIC) #define XMLPUBVAR __declspec(dllimport) extern #else #define XMLPUBVAR extern #endif #endif #define XMLCALL __cdecl #define XMLCDECL __cdecl #else #define XMLPUBFUN #define XMLPUBVAR #define XMLCALL __cdecl #define XMLCDECL __cdecl #endif #if !defined _REENTRANT #define _REENTRANT #endif #endif ========= Problem description ========================= Linking C shared library libopensync.dll Creating library file: libopensync.dll.a CMakeFiles/opensync.dir/format/opensync_time.obj: In function `osync_time_dstchange': f:/opensync/opensync/format/opensync_time.c:1149: undefined reference to `_imp__xmlFree' f:/opensync/opensync/format/opensync_time.c:1164: undefined reference to `_imp__xmlFree' CMakeFiles/opensync.dir/group/opensync_group.obj: In function `osync_group_load': f:/opensync/opensync/group/opensync_group.c:826: undefined reference to `_imp__xmlFree' CMakeFiles/opensync.dir/group/opensync_group.obj: In function `osync_group_is_uptodate': f:/opensync/opensync/group/opensync_group.c:1273: undefined reference to `_imp__xmlFree' CMakeFiles/opensync.dir/group/opensync_member.obj: In function `osync_member_parse_timeout': f:/opensync/opensync/group/opensync_member.c:89: undefined reference to `_imp__xmlFree' CMakeFiles/opensync.dir/group/opensync_member.obj:f:/opensync/opensync/group/opensync_member.c:556: more undefined references to `_imp__xmlFree' follow collect2: ld returned 1 exit status make[2]: *** [opensync/libopensync.dll] Error 1 make[1]: *** [opensync/CMakeFiles/opensync.dir/all] Error 2 make: *** [all] Error 2 Fritz@FRITZ /f/build-opensync Steps to reproduce: 1. Compile something that includes the libxml library with MSYS and MINGW 2. 3. Actual results: The linker reports an undefined reference to _imp__xmlFree Expected results: It should link Does this happen every time? Yes Other information:
I tracked the problem and I think I have a clue what happens. I used the binary library "libxml2-2.7.2.win32.zip" provided by http://www.zlatkovic.com/pub/libxml . That package provides an import library lib/libxml2.lib for MSVC. I compiled the opensync library with MINGW and MSYS. Opensync uses cmake. cmake has a library search function. When running under MINGW, then it takes the first match: 1. lib/libxml2.dll.a (Assuming that this import library was made with MINGW) 2. lib/libxml2.lib (2nd choice) 3. bin/libxml2.dll (3rd choice - MINGW does not need an import library) So the compile process uses the MSVC import library and that seems not to work with the error reports shown in the bug description. That bug description says that the linker cannot find the "xmlFree" symbol which is a variable. Analyzing the library, the xmlFree variable is there. I build a MINGW compliant import library, following the description here: http://www.go-evolution.org/Building_Evolution_on_Windows. So i did: pexports libxml2.dll >libxml2.def dlltool --input-def libxml2.def --output-lib ../lib/libxml2.dll.a That library worked with MINGW (at least it links...) My suggestion is to include the MINGW import libraries in the binary package, because then you can just use the automatic build process with CMAKE to compile with MSVC or MINGW. I also deleted the libxml2.lib which also works with MINGW and CMAKE, because then the libxml2.dll is found. Regards Friedrich
The modification in the header file xmlexports.h modifies the XMLPUBVAR definition. This should result in defining a new variable xmlFree instead of using the one in the library. That compiles, but I guess it does not work.
I found a reference in the MINGW wiki that the import libraries are not compatible between MSVC and MINGW. They describe how to convert between the two. http://www.mingw.org/phpwiki-1.3.14/index.php/MSVC-MinGW-DLL Therefore it would be good if the libxml2.dll.a import library could be bundled together with the package.
I have applied a fix posted by Igor a long time ago (see bug 590302) to try to solve the issue. This won't fix previous builds but as new builds are generated this should avoid the problem ... well I hope so http://mail.gnome.org/archives/xml/2004-February/msg00004.html see thread and the other bug report, Daniel
As Friedrich Beckmann rightly observed, the applied fix totally breaks dynamic linking. For example, the following program: #include <libxml/xmlmemory.h> #include <stdio.h> int main(void) { printf("%p\n", xmlMalloc); xmlMalloc(5); } compiles cleanly but only prints 00000000 before crashing.
Any further input on this bug will be useless. People should discuss this kind of compiler/system specific problems on the mailing-list. Daniel
Is this the final word on this? Because as far as I am concerned, the "fix" is bogus, and not a compiler/system specific problem (or not MinGW broken vs Cygwin at least). I am willing to analyze/explain the problem in detail and discuss/work on possible solutions.
When the Sun goes nova, she who spoke last, will have had the final word. Until then, the back office sorts everything under "revision pending" :-) I have recently built libxml2 with MSYS and MinGW using the usual GNU "configure; make" business. It gave birth to a functional, merry pair called xmllint.exe and xmlcatalog.exe, which were dynamically linked to the also resulting libxml2 dynamic library. Unless I made some arcane mistake, the resulting software worked as expected. Back in time, I insisted on using native Windows toolchains while remaining as compatible to others as possible. Each passing year brought more clearly defined limits to that masochism. A pain once enjoyed, has grown beyond bearing. I feel a strong urge to drop Microsoft's toolchain and take the GNU compiler for future Windows binaries, an act which holds a promise of pain's end. So yes, please do analyse/explain the problem in detail. Not here, let's do it on the mailing list. We shall discuss a solution and we shall produce one.