[
https://issues.apache.org/jira/browse/AXIS2C-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjaya Ratnaweera resolved AXIS2C-1130.
----------------------------------------
Resolution: Fixed
Assignee: Sanjaya Ratnaweera (was: Milinda Lakmal Pathirage)
> 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
> Assignee: Sanjaya Ratnaweera
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
