Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On Thu, Nov 22, 2012 at 5:48 PM, Roumen Petrov wrote: > Hi Earnie, > > Earnie Boyd wrote: >> >> [SNIP] >> >> At least it is not a regression from the previous version. For >> whatever reason those ebcdic tests have never worked on Windows. > > No issue is not related to platform. > > Those tests does not work is standalone iconv is used. Tests past on linux > as iconv, integrated in GNU libc, support this codeset. > > 1) NOTES file from libiconv sources. > 2) http://lists.gnu.org/archive/html/bug-gnu-libiconv/2010-05/msg9.html I've recently learned about http://code.google.com/p/win-iconv/ from watching the Cygwin developers list. I've not downloaded the source yet to give it a try but could be an interesting replacement for GNU iconv for Windows. -- Earnie -- https://sites.google.com/site/earnieboyd ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Hi Earnie, Earnie Boyd wrote: [SNIP] At least it is not a regression from the previous version. For whatever reason those ebcdic tests have never worked on Windows. No issue is not related to platform. Those tests does not work is standalone iconv is used. Tests past on linux as iconv, integrated in GNU libc, support this codeset. 1) NOTES file from libiconv sources. 2) http://lists.gnu.org/archive/html/bug-gnu-libiconv/2010-05/msg9.html -- Earnie -- https://sites.google.com/site/earnieboyd Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On Mon, 19 Nov 2012, Earnie Boyd wrote: At least it is not a regression from the previous version. For whatever reason those ebcdic tests have never worked on Windows. I believe that's just a side effect of not having iconv. I've reported the issue here: https://bugzilla.gnome.org/show_bug.cgi?id=680542 That EBCDIC document should be excluded from the test suite when iconv is unavailable. --Daniel -- Daniel Richard G. || dani...@teragram.com || Software Developer Teragram Linguistic Technologies (a division of SAS) http://www.teragram.com/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On Mon, Nov 19, 2012 at 9:21 AM, Mike Peat wrote: > On 16/11/2012 22:20, Roumen Petrov wrote: > > Unfortunately I have no idea why this issue appear again. > I could build just fine all libraries required by xmlsec in my cross > environment (linux -> mingw host). > > Probably compiler found old headers instead those from source. Please check > with a monitoring tool headers loaded during build process. > > My build environment is quite similar to you - each package is build and > installed in separate directory. I'm sure that in my environment each build > use correct headers and libraries. > > With configure command --build== and --host=..., you trigger > cross-compilation. Try without. > > Roumen > > Roumen > > Thank you! Dropping the --build and --host flags to ./configure seems to > have got me a clean build! Doing "make check" reports only 10 errors over > 2,874 tests - all of them from ./test/ebcdic_566012.xml. I suspect that > constitutes a near-total win! :-) > At least it is not a regression from the previous version. For whatever reason those ebcdic tests have never worked on Windows. -- Earnie -- https://sites.google.com/site/earnieboyd ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On 16/11/2012 22:20, Roumen Petrov wrote: Unfortunately I have no idea why this issue appear again. I could build just fine all libraries required by xmlsec in my cross environment (linux -> mingw host). Probably compiler found old headers instead those from source. Please check with a monitoring tool headers loaded during build process. My build environment is quite similar to you - each package is build and installed in separate directory. I'm sure that in my environment each build use correct headers and libraries. With configure command --build== and --host=..., you trigger cross-compilation. Try without. Roumen Roumen Thank you! Dropping the --build and --host flags to ./configure seems to have got me a clean build! Doing "make check" reports only 10 errors over 2,874 tests - all of them from ./test/ebcdic_566012.xml. I suspect that constitutes a near-total win! :-) Now onwards and upwards to build libxslt, then xmlsec itself! Mike ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Mike Peat wrote: [SNIP] ./configure --prefix=/projects/xmlsec/libxml2-2.9.0 --build=i686-pc-mingw32 --host=i686-pc-winnt --with-iconv=/projects/xmlsec/libiconv-1.14 --with-zlib=/projects/xmlsec/zlib-1.2.7 make Any suggestions *very* gratefully received. :-( Unfortunately I have no idea why this issue appear again. I could build just fine all libraries required by xmlsec in my cross environment (linux -> mingw host). Probably compiler found old headers instead those from source. Please check with a monitoring tool headers loaded during build process. My build environment is quite similar to you - each package is build and installed in separate directory. I'm sure that in my environment each build use correct headers and libraries. With configure command --build== and --host=..., you trigger cross-compilation. Try without. --Mike Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On 16/11/2012 08:06, Daniel Richard G. wrote: On Fri, 9 Nov 2012, Mike Peat wrote: I am trying to do that under MinGW/MSys (having had no joy with MSVC due to msvcrt.dll incompatibilities), but am running into the error "undefined reference to _imp__xmlFree". If anybody knows how to solve this problem then I would be extremely grateful if they would let me know how. That's a sign that you compiled LibXML2 as a static library, but compiled your application to consume LibXML2 as a DLL. When "_imp_" is prepended to a function name, that means the function lives (or is expected to live) in a DLL. Try compiling your application with -DLIBXML_STATIC. --Daniel Daniel - thank you for that (if nothing else it is improving my limited insight), but I am running into the problem in compiling libxml2 itself, rather than in compiling things that depend on it (actually this may be only half true - the error is coming when it gets - I think - to linking xmllint.exe). In any case I think I *need* to build DLLs for what I am doing. What I am trying to do is build xmlsec, and (if I am understanding correctly... improbable, I suspect) that means I have to first build the things it depends on: zlib, libiconv, libxml2, openssl and libxslt. I have (I think) built openssl, libiconv and zlib OK in msys using mingw, but when I try to build libxml2 I run into the error: ... CCLD xmllint.exe xmllint.o: In function `processNode': E:\MinGW\msys\1.0\projects\xmlsec\libxml2-2.9.0/xmllint.c:1820: undefined reference to `_imp__xmlFree' ... followed by many more of the same sort of thing. There is mention of what sounds like this problem in xmlexports.h (line 111): /* * if defined(IN_LIBXML) this raises problems on mingw with msys * _imp__xmlFree listed as missing. Try to workaround the problem * by also making that declaration when compiling client code. */ I am doing (in /projects/xmlsec/libxml2-2.9.0): make clean ./configure --prefix=/projects/xmlsec/libxml2-2.9.0 --build=i686-pc-mingw32 --host=i686-pc-winnt --with-iconv=/projects/xmlsec/libiconv-1.14 --with-zlib=/projects/xmlsec/zlib-1.2.7 make Any suggestions *very* gratefully received. :-( --Mike ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On Fri, 9 Nov 2012, Mike Peat wrote: I am trying to do that under MinGW/MSys (having had no joy with MSVC due to msvcrt.dll incompatibilities), but am running into the error "undefined reference to _imp__xmlFree". If anybody knows how to solve this problem then I would be extremely grateful if they would let me know how. That's a sign that you compiled LibXML2 as a static library, but compiled your application to consume LibXML2 as a DLL. When "_imp_" is prepended to a function name, that means the function lives (or is expected to live) in a DLL. Try compiling your application with -DLIBXML_STATIC. --Daniel -- Daniel Richard G. || dani...@teragram.com || Software Developer Teragram Linguistic Technologies (a division of SAS) http://www.teragram.com/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Does anybody know if this issue has been resolved and if so how? I very much need to get libxml2 to build for a Windows platform - I have an urgent need for a modified version of xmlsec and building the libraries on which it depends (openssl, libiconv, zlib, libxml2 and libxslt) would appear to be prerequisites for doing that. I am trying to do that under MinGW/MSys (having had no joy with MSVC due to msvcrt.dll incompatibilities), but am running into the error "undefined reference to _imp__xmlFree". If anybody knows how to solve this problem then I would be extremely grateful if they would let me know how. The answer may actually be hidden in the Nov 2009 thread on this topic, but I am not enough of a C/C++ developer to be able to figure it out. Please help! On a perhaps related note, does anybody know how to get in contact with Igor Zlatkovic? I have tried emailing igor zlatkovic com, but have had no response so far. TIA Mike Peat ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
>>> On 2009/11/09 at 10:53 PM, Roumen Petrov wrote: > Igor Zlatkovic wrote: >> On 05/11/09 12:50, Martin Schlemmer wrote: > [SNIP] >> 3. You may alter the output files on Windows, such as naming them >> differently (when I last tried, MSYS+MinGW produced a libxml2-2.dll, not >> the hoped for libxml2.dll). This is okay. As an orientation: If some >> greedy corporation must recompile all their Windows software for the new >> libxml2 release, that I don't care about. But if Tor Lillqvist can use >> the thing for his GTK and GIMP work without having to tweak it and thus >> be able to spend more time with his children, I am all in :) > > if we use libtool flag -avoid-version the dll will be created without > version number in name. I propose a patch t > > This year issue with patch (use more compatible autotools based build > system for windows hosts) is closed with resolution "Not GNOME" (!). > I would suggest splitting the patch into different ones that only handle one issue at a time, and then sending them here to be reviewed. Hopefully this is the preferred method for libxml. I can however point out that at least the $(EXEEXT) bits might be bogus, as it would seem to only affect things if cross-compiled to win32 on a non-win32 host. Here on a Windows host with MSYS it works fine, as the convenience wrappers have a .exe extension. So it might rather be a libtool issue when cross-compiling, although I do not have that much experience in this field. Regards, Martin Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
>>> On 2009/11/09 at 10:53 PM, Roumen Petrov wrote: > Martin Schlemmer wrote: > On 11/8/2009 at 8:08 PM, Roumen Petrov wrote: >>> Roumen Petrov wrote: Martin Schlemmer wrote: > Hi, > [SNIP] It seems to me Martin is right but proposed patch is not correct to me. I think that code has to set LIBXML_STATIC internally when is compiled for static library. As libxml build is libtool based we may use PIC definition. libtool when compile source for shared always set -DPIC . >> >> Idea was sort of to remove the need for that. I will respond to Igor's mail > about that. >> >>> Now with reverted commit >>> http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a >>> > >>> 629f7cc9b >>> , i.e. restored "...defined(IN_LIBXML)..." plus following patch >>> == >>> diff --git a/libxml.h b/libxml.h >>> index 3c44c83..1656ac2 100644 >>> --- a/libxml.h >>> +++ b/libxml.h >>> @@ -90,4 +90,7 @@ void __xmlGlobalInitMutexDestroy(void); >>> #endif >>> #endif >>> #endif >>> +#ifndef PIC >>> +# define LIBXML_STATIC >>> +#endif >>> #endif /* ! __XML_LIBXML_H__ */ >>> == >>> >> >> This probably will break MSVC and Borland. Also non-libtool-enabled builds > might also break, >> as "-fPIC -DPIC" is added by libtool, but ignored by gcc on win32 as all >> code > on x86-win32 is already >> position independent. > > No ! -fPIC is not set for gcc mingw target by libtool ! > > For mingw target it is another definition that you already use in the > patch proposed by you : #if defined(DLL_EXPORT) i.e. libtool for > mingw target set -DDLL_EXPORT -DPIC. For gcc on linux it is -fPIC -DPIC > . For other compilers as example -kPIC -DPIC. > In brief one is compiler flag and another is common for all platforms - > it is C preprocessor flag -DPIC. > Never mind here - I missed that it was in an internal header, and thus would not have effected external projects linking against libxml. > >> Not sure what to suggest with this, but to check that with reverted commit > that xmlsec is indeed >> built with -DLIBXML_STATIC if linking to the static version of the library. > > Don't mix preprocessor flags set by other projects when static linking > with libxml is required. > Like Igor pointed out, LIBXML_STATIC needs to be defined if you link against the static version for the current setup. If using pkg-config for a static only build of libxml, this is not an issue, but ... Regards, Martin Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
>>> On 2009/11/09 at 01:26 AM, Igor Zlatkovic wrote: > On 05/11/09 12:50, Martin Schlemmer wrote: Hi, Sorry for the extra late reply - year end with all its deadlines, etc. >> As for fixing this issue - I guess the first will be to back out that patch > again. Then I >> have thought about two possible solutions: >> - deal with linking to static without LIBXML_STATIC defined by keep telling > people >> to not do that. As for the failures with xmllint, etc. I can try to help > debug that if I >> could get more information about build environment, etc. >> - rather use the approach GLIB and friends use - only allow either static or > shared >> builds, and define LIBXML_STATIC via the headers if needed instead of hoping >> the user will remember it >> >> Personally I thought the second approach will be the less painful in future > approach, >> and I made a patch as well as tested it in the situations I could think > could cause the >> failure. I also redid the definitions in xmlexports.h to be more like > glib's which I think >> is more clear. > > If I am not wrong, when I look at your patch, that second approach > results in two sets of headers, one for the dynamic, the other for the > static business. How should the binary distribution look like? Two > packages? That was the idea. Normally they would use either mostly only static or dynamic linking, and if they are not sure, it should not really matter. Just the DLL could be another download for those that only looked for that. > One package with two sets of headers? What about that "static > for DLL", when the user builds a shared library which links to libxml2 > statically? I will be honest if I say that I really do not know if and why this is needed on Windows, so I will rather refrain from answering. > Do we now have three packages or three sets of headers > there? The user will not have to define LIBXML_STATIC, but will likely > chose a wrong package or a wrong set of headers. Nothing is won. > Ah well, like I said, I could see two ways of doing this: - Keep saying "no don't do that" - or just don't allow it If the second is not appropriate, and you don't mind keeping repeating yourself, I do not mind trying to get it working again via another solution. > As for the rest, I am very interested in seeing a working MSYS+MinGW > build which produces libraries usable by Microsoft linker. I am > presently next to unfamiliar with GNU autoconf/automake and given my > dislike for the dreaded build system, I am likely to make myself > familiar with it only in a grave need :) I would be eternaly thankful to > you if you could revise your patch and make the thing work with the > following constraints and freedoms: > > 1. Don't, under any circumstances, break the build on Linux nor alter > the binary compatibility there or on any OS which has Unix roots. Much > of the world, to name GNOME and KDE as prominent examples, depend on > libxml2 and they will whip our backs til the skin comes off if we affect > them. > > 2. Resulting libraries must be usable by Microsoft linker. This means > that those forsaken __declspec(dllimport/dllexport) things must be > defined properly for the build of libxml2 itself and the user code. > With all the development, etc at MSFT, you would have thought that they might have decided by now to try and get on with the time for exporting and importing symbols as well. Especially if they did not mind breaking things with the needed manifest stuff for newer MSCRT, etc > 3. You may alter the output files on Windows, such as naming them > differently (when I last tried, MSYS+MinGW produced a libxml2-2.dll, not > the hoped for libxml2.dll). This is okay. As an orientation: If some > greedy corporation must recompile all their Windows software for the new > libxml2 release, that I don't care about. But if Tor Lillqvist can use > the thing for his GTK and GIMP work without having to tweak it and thus > be able to spend more time with his children, I am all in :) > As Roumen showed, it is possible to not have the version appended by libtool. However, if you want it compatible with GCC and MSVC, you will have to have all three library extensions (.a, .dll.a and .lib), because as I pointed out, GCC search for .dll.a -> .a -> .lib if you did not specify static, and without the .dll.a and -DLIBXML_STATIC things will break ... > 4. If possible, use the same set of headers for the dynamic and the > static business, even if the user has to do a -DLIBXML_STATIC for the > static part to work. I think it is a small requirement which is easily > met and eases the packaging of binaries. > > This now sounds like a whole pile of demands and like I would love to > see it done by someone else. Believe me, if I have had the time to meet > the secrets of GNU autoconf/automake, I would have done it long ago. You > seem to know your way there and can do it much more swiftly than I > could. As a remedy, don't bother with things be
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Martin Schlemmer wrote: On 11/8/2009 at 8:08 PM, Roumen Petrov wrote: Roumen Petrov wrote: Martin Schlemmer wrote: Hi, [SNIP] It seems to me Martin is right but proposed patch is not correct to me. I think that code has to set LIBXML_STATIC internally when is compiled for static library. As libxml build is libtool based we may use PIC definition. libtool when compile source for shared always set -DPIC . Idea was sort of to remove the need for that. I will respond to Igor's mail about that. Now with reverted commit http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a 629f7cc9b , i.e. restored "...defined(IN_LIBXML)..." plus following patch == diff --git a/libxml.h b/libxml.h index 3c44c83..1656ac2 100644 --- a/libxml.h +++ b/libxml.h @@ -90,4 +90,7 @@ void __xmlGlobalInitMutexDestroy(void); #endif #endif #endif +#ifndef PIC +# define LIBXML_STATIC +#endif #endif /* ! __XML_LIBXML_H__ */ == This probably will break MSVC and Borland. Also non-libtool-enabled builds might also break, as "-fPIC -DPIC" is added by libtool, but ignored by gcc on win32 as all code on x86-win32 is already position independent. No ! -fPIC is not set for gcc mingw target by libtool ! For mingw target it is another definition that you already use in the patch proposed by you : #if defined(DLL_EXPORT) i.e. libtool for mingw target set -DDLL_EXPORT -DPIC. For gcc on linux it is -fPIC -DPIC . For other compilers as example -kPIC -DPIC. In brief one is compiler flag and another is common for all platforms - it is C preprocessor flag -DPIC. Not sure what to suggest with this, but to check that with reverted commit that xmlsec is indeed built with -DLIBXML_STATIC if linking to the static version of the library. Don't mix preprocessor flags set by other projects when static linking with libxml is required. Regards, Martin Reference: http://www.gnu.org/software/libtool/manual/html_node/Creating-object-files.html Quote "...(you might have conditional code inside ‘#ifdef PIC’ for example), ...". As in libxml exist another preprocessor directive -DLIBXML_STATIC my suggestion is based on libtool documentation. If modification to libxml.h is acceptable then Borland and MSVC makefiles can set either -DPIC or -DLIBXML_STATIC. Both will work only if first case build system will be more consistent. Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Igor Zlatkovic wrote: On 05/11/09 12:50, Martin Schlemmer wrote: [SNIP] 3. You may alter the output files on Windows, such as naming them differently (when I last tried, MSYS+MinGW produced a libxml2-2.dll, not the hoped for libxml2.dll). This is okay. As an orientation: If some greedy corporation must recompile all their Windows software for the new libxml2 release, that I don't care about. But if Tor Lillqvist can use the thing for his GTK and GIMP work without having to tweak it and thus be able to spend more time with his children, I am all in :) if we use libtool flag -avoid-version the dll will be created without version number in name. I propose a patch t This year issue with patch (use more compatible autotools based build system for windows hosts) is closed with resolution "Not GNOME" (!). [SNIP] Ciao, Igor Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Igor Zlatkovic wrote: On 08/11/09 19:08, Roumen Petrov wrote: [SNIP] +#ifndef PIC +# define LIBXML_STATIC +#endif #endif /* ! __XML_LIBXML_H__ */ == xsltproc work again. That should be okay. PIC will have no meaning for MSVC and the user will still have to define LIBXML_STATIC herself, but that is how it was before. I never realize this just because I never test static build . https://bugzilla.gnome.org/show_bug.cgi?id=454388 - libtool flag -no-undefined is already added - libtool flag -avoid-version no (?) => result incompatible dll name - modification in error.c (?) - MODULE_EXTENSION=".dll" in configure.in for mingw host - about $(EXEEXT) it will be fixed for cross-build environment when project move to libtool 2.x Ciao, Igor Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
>>> On 11/8/2009 at 8:08 PM, Roumen Petrov wrote: > Roumen Petrov wrote: >> Martin Schlemmer wrote: >>> Hi, >>> >> [SNIP] >> It seems to me Martin is right but proposed patch is not correct to me. >> I think that code has to set LIBXML_STATIC internally when is compiled >> for static library. As libxml build is libtool based we may use PIC >> definition. libtool when compile source for shared always set -DPIC . >> Idea was sort of to remove the need for that. I will respond to Igor's mail about that. > Now with reverted commit > http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a > 629f7cc9b > , i.e. restored "...defined(IN_LIBXML)..." plus following patch > == > diff --git a/libxml.h b/libxml.h > index 3c44c83..1656ac2 100644 > --- a/libxml.h > +++ b/libxml.h > @@ -90,4 +90,7 @@ void __xmlGlobalInitMutexDestroy(void); > #endif > #endif > #endif > +#ifndef PIC > +# define LIBXML_STATIC > +#endif > #endif /* ! __XML_LIBXML_H__ */ > == > This probably will break MSVC and Borland. Also non-libtool-enabled builds might also break, as "-fPIC -DPIC" is added by libtool, but ignored by gcc on win32 as all code on x86-win32 is already position independent. Not sure what to suggest with this, but to check that with reverted commit that xmlsec is indeed built with -DLIBXML_STATIC if linking to the static version of the library. Regards, Martin Vrywaringsklousule / Disclaimer: http://www.nwu.ac.za/it/gov-man/disclaimer.html ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On 08/11/09 19:08, Roumen Petrov wrote: > I've cross-build libxml, libxslt , xmlsec with code from repository but > xmlsec application crash. My investigation show that application crash > when code call xmlMalloc. Also I found that xsltproc crash too. > > > Now with reverted commit > http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a629f7cc9b > , i.e. restored "...defined(IN_LIBXML)..." plus following patch Sure, clear as sky. When no clouds are lingering. Sorry, when that commit was discussed, Daniel did alert me and I have seen the patch and in my then obviously thorough blindness I have missed the significance. That can never work because it breaks the import/export of variables. xmlMalloc is a variable (a pointer to a function). > == > diff --git a/libxml.h b/libxml.h > index 3c44c83..1656ac2 100644 > --- a/libxml.h > +++ b/libxml.h > @@ -90,4 +90,7 @@ void __xmlGlobalInitMutexDestroy(void); > #endif > #endif > #endif > +#ifndef PIC > +# define LIBXML_STATIC > +#endif > #endif /* ! __XML_LIBXML_H__ */ > == > > xsltproc work again. That should be okay. PIC will have no meaning for MSVC and the user will still have to define LIBXML_STATIC herself, but that is how it was before. Ciao, Igor ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
On 05/11/09 12:50, Martin Schlemmer wrote: > Hi, Ho, > http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a629f7cc9b That patch is wrong, of course. Sorry, I guess I didn't look closely enough when I saw it. It should be reverted or replaced with something better, as Roumen pointed out. > As for fixing this issue - I guess the first will be to back out that patch > again. Then I > have thought about two possible solutions: > - deal with linking to static without LIBXML_STATIC defined by keep telling > people > to not do that. As for the failures with xmllint, etc. I can try to help > debug that if I > could get more information about build environment, etc. > - rather use the approach GLIB and friends use - only allow either static or > shared > builds, and define LIBXML_STATIC via the headers if needed instead of hoping > the user will remember it > > Personally I thought the second approach will be the less painful in future > approach, > and I made a patch as well as tested it in the situations I could think could > cause the > failure. I also redid the definitions in xmlexports.h to be more like glib's > which I think > is more clear. If I am not wrong, when I look at your patch, that second approach results in two sets of headers, one for the dynamic, the other for the static business. How should the binary distribution look like? Two packages? One package with two sets of headers? What about that "static for DLL", when the user builds a shared library which links to libxml2 statically? Do we now have three packages or three sets of headers there? The user will not have to define LIBXML_STATIC, but will likely chose a wrong package or a wrong set of headers. Nothing is won. As for the rest, I am very interested in seeing a working MSYS+MinGW build which produces libraries usable by Microsoft linker. I am presently next to unfamiliar with GNU autoconf/automake and given my dislike for the dreaded build system, I am likely to make myself familiar with it only in a grave need :) I would be eternaly thankful to you if you could revise your patch and make the thing work with the following constraints and freedoms: 1. Don't, under any circumstances, break the build on Linux nor alter the binary compatibility there or on any OS which has Unix roots. Much of the world, to name GNOME and KDE as prominent examples, depend on libxml2 and they will whip our backs til the skin comes off if we affect them. 2. Resulting libraries must be usable by Microsoft linker. This means that those forsaken __declspec(dllimport/dllexport) things must be defined properly for the build of libxml2 itself and the user code. 3. You may alter the output files on Windows, such as naming them differently (when I last tried, MSYS+MinGW produced a libxml2-2.dll, not the hoped for libxml2.dll). This is okay. As an orientation: If some greedy corporation must recompile all their Windows software for the new libxml2 release, that I don't care about. But if Tor Lillqvist can use the thing for his GTK and GIMP work without having to tweak it and thus be able to spend more time with his children, I am all in :) 4. If possible, use the same set of headers for the dynamic and the static business, even if the user has to do a -DLIBXML_STATIC for the static part to work. I think it is a small requirement which is easily met and eases the packaging of binaries. This now sounds like a whole pile of demands and like I would love to see it done by someone else. Believe me, if I have had the time to meet the secrets of GNU autoconf/automake, I would have done it long ago. You seem to know your way there and can do it much more swiftly than I could. As a remedy, don't bother with things beneath the win32 subdirectory in the source. Once your patch to autoconf/automake based build is complete, I'll fix the Windows scripts. Also, I can help you test your work and see whether my own MSYS+MinGW environment would take it. If this can work out, I'll do my best to adopt it for the dependants (libxslt, xmlsec) and dependencies (zlib, iconv, openssl) and my binary distribution of the whole pack I shall then make with GCC, dropping MSVC. It would be in everyone's best interest, since my binaries are quite widely used and noone can reproduce them due to a lack of my locally patched MSVC. What do you think? Ciao, Igor ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Thanks Martin !!! Roumen Petrov wrote: Martin Schlemmer wrote: Hi, [SNIP] It seems to me Martin is right but proposed patch is not correct to me. I think that code has to set LIBXML_STATIC internally when is compiled for static library. As libxml build is libtool based we may use PIC definition. libtool when compile source for shared always set -DPIC . Roumen I've cross-build libxml, libxslt , xmlsec with code from repository but xmlsec application crash. My investigation show that application crash when code call xmlMalloc. Also I found that xsltproc crash too. Now with reverted commit http://git.gnome.org/cgit/libxml2/commit/?id=a194ccb8d19ddde94c2c04ddf197e6a629f7cc9b , i.e. restored "...defined(IN_LIBXML)..." plus following patch == diff --git a/libxml.h b/libxml.h index 3c44c83..1656ac2 100644 --- a/libxml.h +++ b/libxml.h @@ -90,4 +90,7 @@ void __xmlGlobalInitMutexDestroy(void); #endif #endif #endif +#ifndef PIC +# define LIBXML_STATIC +#endif #endif /* ! __XML_LIBXML_H__ */ == xsltproc work again. Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree
Martin Schlemmer wrote: Hi, [SNIP] It seems to me Martin is right but proposed patch is not correct to me. I think that code has to set LIBXML_STATIC internally when is compiled for static library. As libxml build is libtool based we may use PIC definition. libtool when compile source for shared always set -DPIC . Roumen ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
