Alexander, For libxml2, the configure script is finding and running the xml2-config script that is part of a typical xml2 install to get the appropriate CFLAGS and LIBS values to get to libxml2. Your fallback option, if this gets too complicated, is to simply run configure with --disable-xml and avoid the impacted use cases and code paths.
If you want to get it working with xml enabled, I will outline some choices you have for getting the proper libs pointed to. The ClamAV configure script is finding the xml2-config script and running it based on these lines in your config.log output: checking for libxml2 installation... /usrchecking xml2-config version... 2.9.1checking for xmlreader.h in /usr... foundchecking for xmlTextReaderRead in -lxml2... yesconfigure: Compiling and linking with libxml2 from /usr In your case, the xml2-config is finding and reporting the 32-bit versions from /usr/lib. You should be able to see what it is reporting by running 'xml2-config --libs'. A little bit more info about that helper script is available here as questions 1 and 2 in their "Developers Corner" section : http://xmlsoft.org/FAQ.html You can work around this, as long as you have an xml2-config script that will report the --libs and --cflags values that correspond to your 64-bit libraries instead of the 32-bit ones. But this is exactly why we need a script like that. Only the CFLAGS and LIBS will be different between the 32-bit & 64-bit builds. This is only tricky because the xml2-config is installed to $XML_HOME/bin ... which for both installations would end up being /usr/bin. After all, both sets of includes would be the same, and be in /usr/include/libxml2. The xml2-config is one shared file collision between the side-by-side libxml2 installations that is not actually 100% shareable (barring an undocumented flag that we don't know about, but I digress). Since the xml2-config script is only used during configure execution, I see two ways to resolve this. (1) Temporary: Switch your current xml2-config with one that will report the 64-bit flags and libs values, switch it back when you need 32-bit. These are supposed to be generated with your 32-bit message. (2) Permanent: Make a second folder (e.g. /usr/xml64) with an xml2-config that will report the 64-bit cflags and libs values, and link an "include" subfolder to your real include path, which appears to be "/usr/include". Then add "--with-xml=/usr/xml64" to your configure command line. This is enough for it to get through configure and get to the real values, which are what it will use for building. Steps summary: - Make /usr/xml64 and /usr/xml64/bin directories - Create /usr/xml64/bin/xml2-config script - Link /usr/xml64/include to /usr/include (used to verify existence of a header file) - Run configure, adding " --with-xml=/usr/xml64 " As far as creating a stub xml2-config script, the three xml2-config commands we run as part of configure are these: (1) xml2-config --version In your case, this should return "2.9.1", same as your base version. (2) xml2-config --cflags In your case, this looks like it needs to return "-I/usr/include/libxml2", again the same as your base version. (3) xml2-config --libs In your case, this looks like it needs to return something like "-L/usr/lib64 -lxml2 ", or whatever values are appropriate for your 64-bit lib path. We might add configure options to a future release that will let you force-set libxml2 CFLAGS and LIBS values directly to workaround this case, but this should let you operate for now. Hope this helps, Dave R. On Thu, May 8, 2014 at 4:00 AM, Shawn Webb <sw...@sourcefire.com> wrote: > No worries. Since I'm most familiar with more conventional Linux > distributions, I'm not entirely sure what's going on, but it appears your > compiler/linker is still trying to link against the 32bit libraries rather > than the 64bit ones: -Wl,-rpath -Wl,/usr/lib64/../lib64 -Wl,-rpath > -Wl,/usr/lib64/../lib -Wl,-rpath -Wl,/usr/lib64/../lib64 -Wl,-rpath > -Wl,/usr/lib64/../lib -L/usr/lib /usr/lib/libxml2.so -lz -L/usr/lib64 > > By specifying -L/usr/lib/libxml2.so, that forces the compiler/linker to > attempt link against that library (the 32bit one). Instead, it should be > linking against libxml2 by using -lxml2. I'm the only member of the team > awake at this hour tonight (it's 4am here). I'll bring it up with the team > first thing in the morning and see what they think. I'm sure we can get a > patch out to you soon. > > Thanks, > > Shawn > > > On Thu, May 8, 2014 at 3:49 AM, Alexander Tampermeier < > alexan...@tampermeier.at> wrote: > > > Shawn, > > > > I am very sorry. Obviously I mixed something up totally. > > > > Here is the corrected output of the configure command (now including > > option --disable-silent-rules): http://de.pastebin.de/124760 > > > > And here is the corrected output of the make command: > > http://de.pastebin.de/124761 > > > > Regards > > Alexander > > > > > > Am 08.05.2014 09:29, schrieb Shawn Webb: > > > >> Did you add the --disable-silent-rules to your ./configure run? It looks > >> like step 3 is still producing friendly output. > >> > >> > >> On Thu, May 8, 2014 at 3:21 AM, Alexander Tampermeier < > >> > >> alexan...@tampermeier.at> wrote: > >> > >> Hello Shawn, > >>> > >>> I executed 'make clean distclean'. > >>> > >>> I pasted the output of command #2 (CC="gcc ${BUILD64}" ./configure ...) > >>> at > >>> http://de.pastebin.de/124756 > >>> > >>> Output of command #3 (make) is pasted at http://de.pastebin.de/124757 > >>> > >>> Regards > >>> Alexander > >>> > >>> > >>> Am 08.05.2014 08:40, schrieb Shawn Webb: > >>> > >>> Can you run these commands, and paste the output of commands 2 and 3 > to > >>>> your pastebin service (friendly remember to pipe stderr to stdout): > >>>> > >>>> 1. make clean distclean > >>>> 2. CC="gcc ${BUILD64}" ./configure --prefix=/usr > >>>> --sysconfdir=/etc/clamav > >>>> > >>>> --with-zlib=/usr --with-dbdir=/usr/share/clamav --disable-silent-rules > >>>> 3. make > >>>> > >>>> Thanks, > >>>> > >>>> Shawn > >>>> > >>>> > >>>> On Thu, May 8, 2014 at 2:33 AM, Alexander Tampermeier < > >>>> > >>>> alexan...@tampermeier.at> wrote: > >>>> > >>>> Hello Shawn, > >>>> > >>>>> thank you for your response. > >>>>> > >>>>> This is output of 'file /usr/lib/libxml2.so': > >>>>> /usr/lib/libxml2.so: symbolic link to `libxml2.so.2.9.1' > >>>>> > >>>>> And 'file /usr/lib/libxml2.so.2.9.1' outputs: > >>>>> /usr/lib/libxml2.so.2.9.1: ELF 32-bit LSB shared object, Intel 80386, > >>>>> version 1 (SYSV), dynamically linked, not stripped > >>>>> > >>>>> As my box is cross compiled x86/x64 there are also 64bit libraries, > so > >>>>> that 'file /usr/lib64/libxml2.so' gives: > >>>>> /usr/lib64/libxml2.so: symbolic link to `libxml2.so.2.9.1' > >>>>> > >>>>> And file 'file /usr/lib64/libxml2.so.2.9.1' outputs: > >>>>> /usr/lib64/libxml2.so.2.9.1: ELF 64-bit LSB shared object, x86-64, > >>>>> version > >>>>> 1 (SYSV), dynamically linked, not stripped > >>>>> > >>>>> This is my configure command (building 64bit): > >>>>> CC="gcc ${BUILD64}" ./configure --prefix=/usr > --sysconfdir=/etc/clamav > >>>>> --with-zlib=/usr --with-dbdir=/usr/share/clamav > >>>>> > >>>>> Where 'echo ${BUILD64}' outputs: > >>>>> -m64 > >>>>> > >>>>> I pasted the content of my config.log at > http://de.pastebin.de/124754 > >>>>> > >>>>> Regards > >>>>> Alexander > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Am 08.05.2014 07:52, schrieb Shawn Webb: > >>>>> > >>>>> What's the output of this command: file /usr/lib/libxml2.so > >>>>> > >>>>>> Can you paste (preferably to a pastebin service) your config.log? > What > >>>>>> options did you pass to ./configure? > >>>>>> > >>>>>> > >>>>>> On Thu, May 8, 2014 at 1:48 AM, Alexander Tampermeier < > >>>>>> alexan...@tampermeier.at> wrote: > >>>>>> > >>>>>> I have been using ClamAV on my Linux box (Cross Compiled Linux > from > >>>>>> > >>>>>> Scratch; gcc 4.8.2) for years now and it always compiled well. > >>>>>>> > >>>>>>> Now, compiling version 0.98.3 (and also in 0.98.2) I get the > >>>>>>> following > >>>>>>> compiling error: > >>>>>>> > >>>>>>> CC libclamav_la-fp_sqr_comba_8.lo > >>>>>>> CC libclamav_la-fp_sqr_comba_9.lo > >>>>>>> CC libclamav_la-fp_sqr_comba_generic.lo > >>>>>>> CC libclamav_la-fp_sqr_comba_small_set.lo > >>>>>>> CC libclamav_la-fp_sqrmod.lo > >>>>>>> CC libclamav_internal_utils_la-str.lo > >>>>>>> CC libclamav_internal_utils_la-crypto.lo > >>>>>>> CC libclamav_internal_utils_la-iowrap.lo > >>>>>>> CC libclamav_internal_utils_la-others_common.lo > >>>>>>> CC libclamav_internal_utils_la-qsort.lo > >>>>>>> CC libclamav_internal_utils_la-regcomp.lo > >>>>>>> CC libclamav_internal_utils_la-regerror.lo > >>>>>>> CC libclamav_internal_utils_la-regexec.lo > >>>>>>> CC libclamav_internal_utils_la-regfree.lo > >>>>>>> CCLD libclamav_internal_utils.la > >>>>>>> CCLD libclamav.la > >>>>>>> /usr/lib/libxml2.so: error adding symbols: File in wrong format > >>>>>>> collect2: error: ld returned 1 exit status > >>>>>>> Makefile:969: recipe for target 'libclamav.la' failed > >>>>>>> make[4]: *** [libclamav.la] Error 1 > >>>>>>> make[4]: Leaving directory '/j/development/clamav-0.98.3/libclamav' > >>>>>>> Makefile:3011: recipe for target 'all-recursive' failed > >>>>>>> make[3]: *** [all-recursive] Error 1 > >>>>>>> make[3]: Leaving directory '/j/development/clamav-0.98.3/libclamav' > >>>>>>> Makefile:893: recipe for target 'all' failed > >>>>>>> make[2]: *** [all] Error 2 > >>>>>>> make[2]: Leaving directory '/j/development/clamav-0.98.3/libclamav' > >>>>>>> Makefile:649: recipe for target 'all-recursive' failed > >>>>>>> make[1]: *** [all-recursive] Error 1 > >>>>>>> make[1]: Leaving directory '/j/development/clamav-0.98.3' > >>>>>>> Makefile:477: recipe for target 'all' failed > >>>>>>> make: *** [all] Error 2 > >>>>>>> > >>>>>>> Does anybody know how to get around this? I already recompiled > >>>>>>> libxml2 > >>>>>>> (v2.9.1) but the error persists. > >>>>>>> ClamAV v0.98.1 still compiles perfectly. > >>>>>>> > >>>>>>> Regards > >>>>>>> Alexander > >>>>>>> _______________________________________________ > >>>>>>> Help us build a comprehensive ClamAV guide: > >>>>>>> https://github.com/vrtadmin/clamav-faq > >>>>>>> http://www.clamav.net/support/ml > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> > >>>>>>> Help us build a comprehensive ClamAV guide: > >>>>>> https://github.com/vrtadmin/clamav-faq > >>>>>> http://www.clamav.net/support/ml > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> > >>>>> Help us build a comprehensive ClamAV guide: > >>>>> https://github.com/vrtadmin/clamav-faq > >>>>> http://www.clamav.net/support/ml > >>>>> > >>>>> _______________________________________________ > >>>>> > >>>> Help us build a comprehensive ClamAV guide: > >>>> https://github.com/vrtadmin/clamav-faq > >>>> http://www.clamav.net/support/ml > >>>> > >>>> > >>>> _______________________________________________ > >>> Help us build a comprehensive ClamAV guide: > >>> https://github.com/vrtadmin/clamav-faq > >>> http://www.clamav.net/support/ml > >>> > >>> _______________________________________________ > >> Help us build a comprehensive ClamAV guide: > >> https://github.com/vrtadmin/clamav-faq > >> http://www.clamav.net/support/ml > >> > >> > > _______________________________________________ > > Help us build a comprehensive ClamAV guide: > > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/support/ml > > > _______________________________________________ > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > http://www.clamav.net/support/ml > -- --- Dave Raynor Vulnerability Research Team dray...@sourcefire.com _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
