Re: [xml] Build failure on Sparc solaris using gcc and binutils

[Rob Richards <rrichards cdatazone org>]

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]
> > > >         
> > > > > My suggestion as long -M ld option is not clear ;-)
> > > > >
> > > > > VERSION_SCRIPT_FLAGS=
> > > > > $($LD --help 2>&1 | grep -- --version-script >/dev/null) && \
> > > > >   VERSION_SCRIPT_FLAGS=-Wl,--version-script=
> > > > >           
> > > > May be is time project to upgrade libtool to 2.+ version where
> > > > exist  flag with_gnu_ld.
> > > >         
> > >  Argh, maybe that's the problem, any suggestion on how to best do this ?
> > >       
> > The last libtool stable:
> > - 2.2.6a (actually 2.2.6 but maintenance issue with tarbal and
> > updated archive is with 2.2.6a in name);
> > - 1.5.26 - the last pre 2x that end 1x versions.
> >
> >
> > Next of mail is a brief list of steps to switch a project to 2.x
> > version (We has to check what is really required for libxml2).
> >
> > 1)
> > Before 2.x version libtool team advise libtool.m4 file to be
> > included in acinclude.m4. This was problem when a project/user try
> > to user more recent libtool version but didn't upgrade acinclude
> > file.
> > For 2x series libtool team advise project to use AC_CONFIG_MACRO_DIR
> > For reference see libtool macro LT_OUTPUT as example:
> > http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html#index-LT_005fOUTPUT-113
> >
> > So this is first step to remove libtool.m4 form acinclude.m4 if
> > applicable to project and to add AC_CONFIG_MACRO_DIR([m4]) to
> > configure script. Command libtoolize (2+) will install into
> > specified directory libtool m4-files.
> >
> >
> > 2)
> > libtool 2.x provide backward compatible macros (sounds good). May be
> > current repository provide stable backward compatibility for all
> > projects. Obsolete macros are listed in lt~obsolete.m4. Also see
> > comment in file.
> >
> > To ensure more user friendly switch to 2.x version I would like to
> > suggest switch to new macros from 2x series: LT_INIT and etc.
> > instead to  use backward compatible macros. The sample configure
> > script that will work with 1.x and 2.x versions:
> > =================================================
> > dnl Add libtool support.
> > m4_ifdef(
> >   [LT_INIT],
> >   [
> >     LT_INIT([win32-dll])
> >     LT_LANG([Windows Resource])
> >     LT_CONFIG_LTDL_DIR([libltdl])
> >     LTDL_INIT
> >     # The lt_dladvise_init symbol was added in libtool-2.2
> >     if test "x$with_included_ltdl" != "xyes"; then
> >       save_CPPFLAGS="$CPPFLAGS"
> >       save_LDFLAGS="$LDFLAGS"
> >       CPPFLAGS="$CFLAGS $LTDLINCL"
> >       LDFLAGS="$LDFLAGS $LIBLTDL"
> >       AC_CHECK_LIB([ltdl], [lt_dladvise_init],
> >         [],
> >         [AC_MSG_ERROR([installed libltdl is too old])])
> >       LDFLAGS="$save_LDFLAGS"
> >       CPPFLAGS="$save_CPPFLAGS"
> >     fi
> >   ],
> >   [
> >     AC_WITH_LTDL
> >     AC_LIBLTDL_CONVENIENCE
> >     AC_LIBTOOL_WIN32_DLL
> >     AC_LIBTOOL_RC
> >     AC_PROG_LIBTOOL
> >   ]
> > )
> > =================================================
> > May be only LT_INIT([win32-dll]) and
> > AC_LIBTOOL_WIN32_DLL+AC_PROG_LIBTOOL is enough for libxml2 - no
> > libtool dynamic loading , no windows resource files.
> >
> >
> > 3) Some configure script may run libtool script at configure time.
> > In 2.x script is generated by AC_OUTPUT so for backward
> > compatibility project may add macro LT_OUTPUT to configure script.
> >
> >
> > 4) May be I miss something.
> >     
>
>   Hum, that's an old thread but I think still relevant.
> I tried to update some of the configure and auto* files, with
> the idea that due to the coming new zlib release, a new release would
> be needed this week.
> I'm not sure how much we need to change for libtool, right now in my git
> checkout I see in 'libtool':
>
> # Which release of libtool.m4 was used?
> macro_version=2.2.6b
> macro_revision=1.3017
>
> so somehow it seems we upgrated but maybe some of the steps you outlined
> need to be put in place. I don't check with win32 myself be it native or
> mingw so maybe you can have a look, and possibly provide an additional patch
> if you find problems,
>
>   thanks !
>
>   

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:

diff --git a/libxml.h b/libxml.h
index 1656ac2..6c6ddb0 100644
--- a/libxml.h
+++ b/libxml.h
@@ -90,7 +90,7 @@ void __xmlGlobalInitMutexDestroy(void);
#endif
#endif
#endif
-#ifndef PIC
+#if !defined(PIC) && defined(__MINGW32__)
#  define LIBXML_STATIC
#endif
#endif /* ! __XML_LIBXML_H__ */

Rob