You are right that there are some under-the-hood changes in our configure. Much of that was modularizing an 1860-line configure.ac into a 250-line master file with sections broken out into m4 includes. I think it is the combination of that along with how we identify and link to the new dependencies introduced. As I take a closer look, there is a check in the libz section that is explicitly omitting adding /usr/lib as an additional path in LDFLAGS. You may be able to resolve this similarly, with changes to the m4 files and re-building configure.
The two other files that would help trace this are the "config.log" generated from running configure, and the "libclamav/Makefile" that is built. If you could share those, that would be the next place to look for information. Dave R. On Thu, May 8, 2014 at 4:52 PM, Alexander Tampermeier < alexan...@tampermeier.at> wrote: > Dave, > > thank you for your detailed response. First, I tried to configure with > option "--disable-xml" as you suggested but this attempt led to further > problems: > > 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/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz > /usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz > /usr/bin/ld: skipping incompatible /usr/lib/libbz2.so when searching for > -lbz2 > /usr/bin/ld: skipping incompatible /usr/lib/libbz2.a when searching for > -lbz2 > /usr/lib/libltdl.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 > > So, I got into the same "error adding symbols"-trouble as before with > libxml2, now with libltdl. First I thought, that this might be a general > issue with my libraries. But then I tried to recompile several packages > including php (which also uses libxml2) and everything compiled perfectly. > This makes me believe that this issue might not be related to my system > only. > > My "Cross-Compiled Linux From Scratch" system relies on a > "multiarch-wrapper" script as desribed in http://cross-lfs.org/view/ > CLFS-2.1.0/x86_64/final-system/multiarch_wrapper.html to switch between > 32bit and 64bit. I tested this wrapper script and it definitely can switch > between 32bit and 64bit as expected. I also tried to temporarily substitute > xml2-config for 32bit with the one used for 64bit as you suggested but that > also ends up in a compilation error: > > 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 > > The permanent workaround you suggested also led to the "error adding > symbols"-error as described above. > > But what definitely is strange: > "xml2-config-32 --libs" and "xml2-config-64 --libs" both bring the same > result: "-lxml2 -lz -lm -ldl" > "./xml2-config-32 --cflags" and "./xml2-config-64 --cflags" both bring the > same result: "-I/usr/include/libxml2" > > So finally, I temporarily changed both scripts (xml2-config-32 and > xml2-config-64) to always give back "-L/usr/lib64 -lxml2 -lz -lm -ldl" when > calling either script with option "--cflags" directly or by calling the > wrapper script "xml2-config". But this still resulted in the same error as > described above. Could this mean that the reason for the compilation error > might not (only) lie in "xml2-config"? > > > What really is confusing: > As clamav v0.98.1 and other packages still compile perfectly I suspect > that the issue has also something to do with changes in clamav v0.98.2 and > 0.98.3 regarding the way clamav searches for needed libraries. Could you > verify such a conclusion? > > > Regards > Alexander > > > Am 08.05.2014 18:15, schrieb David Raynor: > >> 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 >>> >>> >> >> > _______________________________________________ > 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
