Re: [xml] autotool based vs. plain make builds

[Roumen Petrov <bugtrack roumenpetrov info>]

Rob Richards wrote:
> Roumen Petrov wrote:
> > Rob Richards wrote:
> > > Roumen Petrov wrote:
> > > > I will hijack mail thread as change subject and I will exclude
> > > > Matthias Jung as hijacked post is for Solaris.
> > > >
> > > > The original issue start here
> > > > "http://mail.gnome.org/archives/xml/2009-November/msg00005.html";
> > > >
> > > >
> > > > Rob Richards wrote:
> > > > > Daniel Veillard wrote:
> > > > > > On Fri, Oct 23, 2009 at 12:09:19AM +0300, Roumen Petrov wrote:
> > > > > > > Daniel Veillard wrote:
> > > > > > > > On Thu, Oct 22, 2009 at 12:26:27AM +0300, Roumen Petrov wrote:
> > > > > > > > > Matthias Jung wrote:
> > > > [SNIP]
> > > >
> > > > > A piece of the patch from this appears to break at least the native
> > > > > windows build by forcing LIBXML_STATIC to always be defined.
> > > > > The change in question is here:
> > > > > http://git.gnome.org/browse/libxml2/diff/libxml.h?id=120a269976f4198e54cc7b848dd78fca81bb9179
> > > > >
> > > > >
> > > > >
> > > > > which is part of this collection of changes:
> > > > > http://git.gnome.org/browse/libxml2/commit/?id=120a269976f4198e54cc7b848dd78fca81bb9179
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > If this is only for mingw then the following would be more
> > > > > appropriate imo:
> > > >
> > > > Technically no . It is for all libtool based builds.
> > > >
> > > > It is my mistake as I don't provide complete patch in above mentioned
> > > > mail thread (
> > > > http://mail.gnome.org/archives/xml/2009-November/msg00020.html ).
> > > >
> > > > Why is not mingw specific. The one of the libtool branches is for
> > > > support of MSVC compiler. No idea when this branch will be merger
> > > > mainstream. After merge usres that will try to use autotool(with
> > > > libtool) based build will enter into same issue.
> > > >
> > > >
> > > > So I would like to propose to add flag -DNOLIBTOOL to plain make file
> > > > builds.
> > > > - win32/Makefile.bcb
> > > > replace CPPFLAGS = -I"$(XML_SRCDIR)\include" with
> > > > CPPFLAGS = -I"$(XML_SRCDIR)\include" -DNOLIBTOOL
> > > >
> > > > - win32/Makefile.mingw
> > > > replace CPPFLAGS += -I$(XML_SRCDIR)/include with
> > > > CPPFLAGS += -I$(XML_SRCDIR)/include -DNOLIBTOOL
> > > >
> > > > - win32/Makefile.msvc
> > > > replace CPPFLAGS = /nologo /I$(XML_SRCDIR)\include with
> > > > CPPFLAGS = /nologo /I$(XML_SRCDIR)\include /D "NOLIBTOOL"
> > > >
> > > > - Makefile.win ???
> > > > No idea. May be is better to be removed from sources.
> > > >
> > > > and finally change in libxml.h :
> > > > #ifndef NOLIBTOOL
> > > > #ifndef PIC
> > > > #if !defined(PIC) && defined(__MINGW32__)
> > > > # define LIBXML_STATIC
> > > > #endif
> > > > #endif
> > > >
> > > > Currently #define LIBXML_STATIC from libxml.h impact only windows
> > > > platform (cf. threads.c ). This could change in future if new code is
> > > > added under #ifdef LIBXML_STATIC statement.
> > >
> > > That works for the win32 build (at least msvc). I ended up using the
> > > following block of code though:
> > >
> > > #ifdef IN_LIBXML
> > > #ifdef __GNUC__
> > > #ifdef PIC
> > > #ifdef linux
> > > #if (__GNUC__ == 3 && __GNUC_MINOR__ >= 3) || (__GNUC__ > 3)
> > > #include "elfgcchack.h"
> > > #endif
> > > #endif
> > > #elif !defined(NOLIBTOOL)
> > > # define LIBXML_STATIC
> > > #endif
> > > #endif
> > > #endif
> > > #endif /* ! __XML_LIBXML_H__ */
> > >
> > > Rob
> > No above is not correct as it is not for GNU compiler .
> > GNU libtool define C preprocessor directive -DPIC for shared builds
> > and appropriate flag for compiler.
> > This mean that case has to be outside #ifdef __GNUC__ and -DPIC is
> > opposite to -DLIBXML_STATIC.
> >
> > Roumen
>
> Ok, I attached a patch for this which works for msvc currently. libxml.h
> now just checks for ! defined(PIC) and ! defined(NOLIBTOL) to determine
> if it should explicitly define LIBXML_STATIC.
Now this part looks good.


> Also, the NOLIBTOOL
> defines needed to be moved to the "compiler and its options" section
> though I also did leave it for the preprocessor section too.

Uhh, I didn't note that CFLAGS don't include CPPFLAGS

> I assume
> this will work for mingwin and borland too though dont have a test
> environment to try them.
I hope so :).

> Rob

Thanks  that you bring this issue again and as least is proposed working 
patch for all impacted builds.


Roumen