>>> 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/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?
> 

I have no issue if its understood that my time for the next month or
two will be very limited.

I however am a bit unclear as to what should be fixed if we keep the
dual linking approach.
As far as I am concerned, if you do things properly on a Windows host,
from 2.6.28 (last I
can track down that worked fine here without testing previous
versions), it works fine - that
is of course with that commit reverted.

http://mail.gnome.org/archives/xml/2004-February/msg00004.html 
*----------------------------------------------------------------------
This (with libxml-2.6.5) I can confirm.  I have not looked to why, but
the import library for the
DLL was never created, only the static, so when it should have linked
xmllint, etc against the
 dynamic, it used the static, and boom ....

https://bugzilla.gnome.org/show_bug.cgi?id=590302
*------------------------------------------------------
With no version information, I will either assume that it was an older
version of libxml, or
a bug with specific version of binutils and gcc 4.4.0.

https://bugzilla.gnome.org/show_bug.cgi?id=561340
*------------------------------------------------------
Not enough info, so going to assume that the static version of the
library was used without
defining LIBXML_STATIC, or it was the .lib and no .dll.a import library
issue.


What I can suggest though, is to revert the patch, and adding me to
bugs with libxml-2.7.7
(or at whatever version the patch is reverted), and making sure your
binaries include both
.lib and .dll.a (can just relink it or copy the .lib to .dll.a).  Thus
I will help to track down the
issue for later versions if any.

An alternative I have started to look at, but have not fully researched
yet, is the way both
gettext and libiconv does it (via Bruno Haible's dll magic), but I know
that for gcc-2.95.*
at least this break (think you need gcc3 or later).


So yes, I am willing, but those in charge will need to specify the
direction that they want
to go first.


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

Reply via email to