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 <[email protected]> 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 <
[email protected]> 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 <
[email protected]> 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 <
[email protected]> 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 <
[email protected]> 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
