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

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:
My suggestion as long -M ld option is not clear ;-)

$($LD --help 2>&1 | grep -- --version-script>/dev/null)&&  \

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).

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
For 2x series libtool team advise project to use AC_CONFIG_MACRO_DIR
For reference see libtool macro LT_OUTPUT as example:

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.

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.
     LT_LANG([Windows Resource])
     # The lt_dladvise_init symbol was added in libtool-2.2
     if test "x$with_included_ltdl" != "xyes"; then
       AC_CHECK_LIB([ltdl], [lt_dladvise_init],
         [AC_MSG_ERROR([installed libltdl is too old])])
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.

So I just finish rebuild of libxml2, libxslt, and xmlsec (linux+mingw-cross).

   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?

Ok my is 2.2.6 FSF, i.e. without patches.


so somehow it seems we upgrated but maybe some of the steps you outlined
need to be put in place.

For the solaris I need to check the mail-thread again and to remember how to implement.
Quick check in build tree show:
$ grep gnu_ld *

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,

For mingw build to repository version is applied attached patch mingw-20100310.patch :
- include/libxml/xmlexports.h (fatal)
  to restore export decoration otherwise xsltproc and xmlsec crash
  credits to ? (another thread)

- libxml.h (important)
  idea is to define LIBXML_STATIC for static build
  credits to ? (another thread)

- (FYI)
  may be beacuse source is bootstrapped with autoconf 2.65

- (feature request)
  this patch will enable module support for mingw* builds

- (feature request)
  Flags for testdso (if module support is enabled)

   thanks !



Attachment: mingw-20100310.patch
Description: Text Data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]