Re: [xml] undefined reference to / segfault on _imp__xmlFree in code::blocks on WinXP

2013-01-09 Thread Martin Schlemmer
 On 1/9/2013 at  4:59 PM, Martin Schlemmer wrote:

snip

 If its a later version of libxml with shared import library (ie. linking to 
 the DLL via the .dll.a import library - if built via ./configure  make; I 
 do not use)

This should have been: I do not use win32/Makefile.mingw or win32/configure.js)


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
https://mail.gnome.org/mailman/listinfo/xml


Re: [xml] undefined reference to / segfault on _imp__xmlFree in code::blocks on WinXP

2013-01-09 Thread Martin Schlemmer
[Resend as it seemed to have gotten lost]

 On 1/8/2013 at  5:29 PM, Eduard Budaca budaca.edu...@gmail.com wrote:
 I am using Code::Blocks with the GNU GCC compiler on Windows XP.
 I am currently learning to use libxml2 so I am trying the tutorials.
 Everything worked fine until trying xmlFree(), whick resulted in an
 undefined reference.
 After searching in the headers I found the #define IN_LIBXML fix, which
 resulted in a segfault.
 After trying a commit which required editing the xmlexports.h file, I got a
 segault again.
 
 So, since this bug has (apparently) been around for a while, I would like
 to know if there is a fix for it or a replacement for xmlFree()

Some questions:
- Where did you get the binaries for libxml
- What version of libxml
- Which import library are you linking to (shared/static)

If its a later version of libxml with shared import library (ie. linking to the 
DLL via the .dll.a import library - if built via ./configure  make; I do not 
use), it should just work, if its the static version (normally .a) , then you 
should define LIBXML_STATIC (-DLIBXML_STATIC to CFLAGS/CXXFLAGS). If its the 
latter case (static) and you did not define LIBXML_STATIC, then its *not a bug*.

If you built it yourself and used win32/Makefile.mingw, then you probably will 
run into issues, as it generates:

  libxml2.lib
  libxml2.a

which will cause problems (and probably *is a bug*), as the default search 
order for LD with MinGW is:

  libxml2.dll.a
  xml2.dll.a
  libxml2.a
  xml2.lib
  libxml2.dll
  xml2.dll
  xml2.lib

and will cause libxml2.a to be found first even with the shared import 
library present (libxml2.lib - rather a MSVC naming scheme than a GCC/LD 
one), and as you probably did *not* have LIBXML_STATIC defined, you are back to 
the undefined reference. In this case I guess you can just remove libxml2.a 
if you want to link to the DLL and not static, else add the define...

Also, I guess not using import libraries generated with gcc/binutils (ie. .LIB 
via MSVC) could cause other problems.


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
https://mail.gnome.org/mailman/listinfo/xml


Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree

2009-11-17 Thread Martin Schlemmer
 On 2009/11/09 at 01:26 AM, Igor Zlatkovic i...@zlatkovic.com
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 beneath the win32
 subdirectory in the source. Once your patch to autoconf

Re: [xml] MSYS and MINGW: undefined reference to _imp__xmlFree

2009-11-17 Thread Martin Schlemmer
 On 2009/11/09 at 10:53 PM, Roumen Petrov bugtr...@roumenpetrov.info wrote:
 Martin Schlemmer wrote:
 On 11/8/2009 at 8:08 PM, Roumen Petrov bugtr...@roumenpetrov.info 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

2009-11-17 Thread Martin Schlemmer
 On 2009/11/09 at 10:53 PM, Roumen Petrov bugtr...@roumenpetrov.info 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