shlomif / perl-XML-LibXML

The XML-LibXML CPAN Distribution for Processing XML using the libxml2 library
https://metacpan.org/release/XML-LibXML
Other
17 stars 35 forks source link

Android 9 + termux 0.68 + clang 8.0.0 build: header file 'libxml/xmlmemory.h' not found and failure to link to libxml2.so #33

Closed stuart-little closed 5 years ago

stuart-little commented 5 years ago

I've installed the module on a phone as in the title (aarch64 architecture), using termux as my terminal emulator and package provider .

The output of perl -V is here (it's v5.28.2).

During the build/installation I encountered the following issues that I thought might be good to document.


First, with a plain perl Makefile.PL followed by make I get

fatal error: 'libxml/xmlmemory.h' file not found

during the build. Apparently, the line

CCFLAGS => Alien::Libxml2->cflags . " $Config{ccflags}",

in Makefile.PL manages to get the include directory

-I/data/data/com.termux/files/usr/include

into the Makefile, but the problematic header file libxml/xmlmemory.h is one level down, in

/data/data/com.termux/files/usr/include/libxml2

so I add that by hand in Makefile.PL (with an -I in front, appending it to the value of the CCFLAGS key; see below for the full diff).


Secondly, after implementing that change and making and make install-ing successfully there's a separate issue:

Trying to run any scripts with use XML::LibXML results in an error to the effect that the linker cannot find the symbol xmlMemMalloc (which appears in the library libxml2.so I'm supposed to link against).

The problem seems to be that the line

LIBS => [ Alien::Libxml2->libs ],

in Makefile.PL fails to pass the flag -lxml2 to the Makefile, which as a result has no EXTRALIBS and LDLOADLIBS (which are both supposed to read -lxml2, based on pattern-matching to x86_64 systems I could build on successfully).

So I had to add -lxml2 by hand to the value of the LIBS key in Makefile.PL.

All in all, the modifications look like this:

$ diff <old Makefile.PL file> <new Makefile.PL file>
76,77c76,77
<   CCFLAGS => Alien::Libxml2->cflags . " $Config{ccflags}",
<   LIBS    => [ Alien::Libxml2->libs ],
---
>   CCFLAGS => Alien::Libxml2->cflags . " $Config{ccflags}"  . " -I/data/data/com.termux/files/usr/include/libxml2",
>   LIBS    => Alien::Libxml2->libs .  " -lxml2",

Everything works after this (succesful perl Makefile.PL + make + make install + the package behaves as expected).

As far as I can tell those Alien::Libxml2 calls in the two lines I modified provide nothing: running perl Makefile.PL does spit out two warnings:

Use of uninitialized value in concatenation (.) or string at Makefile.PL line 73

Line 73 is where the definition of that hash with keys CCFLAGS, LIBS etc. starts. I don't know why Alien::Libxml2 misbehaves in this fashion, resulting in having to do manual correction.


I hope this helps others dealing with similar problems. I am not even certain this is the right forum, but it seemed amenable for documentation somewhere..

shlomif commented 5 years ago

Hi!

Thanks for the report. Try reporting the issues with the Alien package at https://metacpan.org/pod/Alien::Libxml2 .

stuart-little commented 5 years ago

Thanks!

After some back and forth on the Alien::Libxml2 github page we traced it back to not having a package called libiconv-dev installed on my system (that package provides the iconv.h header file, which Alien wanted).

After installing that both Alien::Libxml2 and XML::LibXML install fine through CPAN, with or without tests.

shlomif commented 5 years ago

Thanks!

After some back and forth on the Alien::Libxml2 github page we traced it back to not having a package called libiconv-dev installed on my system (that package provides the iconv.h header file, which Alien wanted).

After installing that both Alien::Libxml2 and XML::LibXML install fine through CPAN, with or without tests.

@stuart-little : I'm glad to hear that. Is there anything we can do to prevent future users from having this problem (see https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/ ) or should I just close this issue?

stuart-little commented 5 years ago

I'm not sure there's anything to do at your end to mitigate the problem, which seems somewhat far removed from XML::LibXML.

Perhaps the best solution would be for libxml2-dev to pull in libiconv-dev, as suggested in the Alien thread I linked to above, but that would be something specific to the termux package manager.

I think it's reasonable to close the issue.

shlomif commented 5 years ago

@stuart-little : thanks, will do.