[ https://issues.apache.org/jira/browse/AXIS2C-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Samisa Abeysinghe reassigned AXIS2C-1130: ----------------------------------------- Assignee: Milinda Lakmal Pathirage Apply this patch, so that Steve can test before we put out the next release > 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: Milinda Lakmal Pathirage > 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]