axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frederic Heem (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2C-1130) Build system's use of libxml2 needs cleaning up
Date Thu, 08 May 2008 14:52:56 GMT

    [ https://issues.apache.org/jira/browse/AXIS2C-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595273#action_12595273
] 

Frederic Heem commented on AXIS2C-1130:
---------------------------------------

Actually, there is another problem regarding libxml2, when it is not used, the auto* tools
stills looks for libxml2. This is an issue when crosscompiling on an embedded system where
libxml2 is not present.


> Build system's use of libxml2 needs cleaning up
> -----------------------------------------------
>
>                 Key: AXIS2C-1130
>                 URL: https://issues.apache.org/jira/browse/AXIS2C-1130
>             Project: Axis2-C
>          Issue Type: Improvement
>          Components: build system
>    Affects Versions: 1.4.0
>         Environment: CentOS 4.6 (linux), GCC 4.2.3
>            Reporter: Steve Nairn
>            Priority: Minor
>         Attachments: libxml2.patch
>
>
> Now that 1.4.0 is out of the way.... I'm in the process of getting Axis2/C to build on
Solaris, AIX, HP/UX, Tru64 and Windows (with MinGW) so am modifying the "configure.ac"s and
"Makefile.am"s. Rather than try and submit huge patches that achieve this I thought I'd have
more luck getting patches accepted if they're smaller and more manageable.
> One problem I've come across is the way libxml2 is used in the build system (if "--enable-libxml2"
is supplied).
> The first problem is that it's difficult to use libxml2 if it is installed in a non-standard
place so extra CFLAGS and LDFLAGS must be supplied for the build. This should not be the case
as the configure script(s) use the PKG_CHECK_MODULES macro to check for libxml2. This uses
pkg-config to find out if the libxml2 package is installed and if so, what CFLAGS and LDFLAGS
are required to use the package. Unfortunately this information is not then used in the Makefile(s).
> The second problem is the samples and tools configure scripts check whether to use guththila
or libxml2 when they don't need to. The axiom configure script needs to know so that it can
build the correct wrapper library and the top level configure script needs to know so it can
pass the option to the axiom configure script and so it can configure in guththila (if guththila
is enabled). The samples and tools shouldn't care which parser is being used so don't need
to check (the check just adds unnecessary complexity).
> The third problem is that the Makefile in axiom/src/parser/libxml2 builds libaxis2_libxml2.la
as well as libaxis2_parser.la which appears to be a bit pointless. The libraries are identical
and nothing uses libaxis2_libxml2,la. This can be removed.
> The final problem is that lots of Makefiles explicitly mention the libxml2 or guththila
libraries when they don't need to. The build system uses libtool which maintains the dependency
information required to use a library. When libaxis2_parser (either the guththila or libxml2
version) is built libtool adds the dependent libraries (either guththila or libxml2) to the
libaxis2_parser.la file. When anything else is linked with libaxis2_parser.la by libtool then
libtool will automatically include the right dependent libraries to the link (In fact, for
the same reason very little needs to explicitly link with libaxis2_parser.la since if things
link to libaxis2_axiom.la libtool makes sure they get the right libaxis2_parser as it is required
to build libaxis2_axiom.la).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message