Bugzilla – Bug 11747
libclamav.map
Last modified: 2022-05-17 17:15:24 EDT
ld: warning: ignoring file ../libclamav/libclamav.map, file was built for unsupported file format ( 0x43 0x4C 0x41 0x4D 0x41 0x56 0x5F 0x50 0x55 0x42 0x4C 0x49 0x43 0x20 0x7B 0x0A ) which is not the architecture being linked (x86_64): ../libclamav/libclamav.map
Hello. I apologize in the delay of getting back to you. What system are you building for? Addressing this warning has been on my radar for some time now. I've observed it when building for macOS and suspect it may be a part of the reason why I am unable to step into libclamav functions when debugging clamscan on macOS.
(In reply to Micah Snyder from comment #1) > Hello. I apologize in the delay of getting back to you. > > What system are you building for? Addressing this warning has been on my > radar for some time now. I've observed it when building for macOS and > suspect it may be a part of the reason why I am unable to step into > libclamav functions when debugging clamscan on macOS. MacOS X
I guess it's worth noting that I was being an idiot earlier and that I couldn't step into libclamav functions when debugging on macOS because I was using gdb instead of lldb, when clamav was built using clang -- not gcc. lldb works fine. On the original topic of this ticket - I still haven't investigated to really figure out what's with the ld warning you reported.
I still see it with clamav 0.101.2 on macos 10.13.6. ld: warning: ignoring file ../libclamav/libclamav.map, file was built for unsupported file format ( 0x43 0x4C 0x41 0x4D 0x41 0x56 0x5F 0x50 0x55 0x42 0x4C 0x49 0x43 0x20 0x7B 0x0A ) which is not the architecture being linked (x86_64): ../libclamav/libclamav.map
>file /opt/src/clamav-0.101.2/libclamav/libclamav.map /opt/src/clamav-0.101.2/libclamav/libclamav.map: ASCII text
Yup. We haven't made any changes yet for how we define the exported symbols in libclamav. I certainly would like to do this in a cross platform way, but I don't know when we'll get around to it. Please don't worry about this for now. It's not a serious concern.
Possibly similar to 23220 however on 64-bit recent Debian sid with trivial code I see : https://www.webb-dev.co.uk/category/crypto/ mimas$ mimas$ uname -a http://www.compilatori.com/category/services/ Linux mimas 5.10.0-6-sparc64 #1 Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux mimas$ http://www.acpirateradio.co.uk/category/services/ mimas$ mimas$ /usr/bin/gcc --version http://www.logoarts.co.uk/category/services/ gcc (Debian 10.2.1-6) 10.2.1 20210110 Copyright (C) 2020 Free Software Foundation, Inc. http://www.mconstantine.co.uk/crypto/kilimanjaro/ This is free software; see the source for copying conditions. There is NO http://www.slipstone.co.uk/category/services/ warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. mimas$ http://embermanchester.uk/category/services/ mimas$ mimas$ cat -n foo.c http://connstr.net/category/services/ 1 2 #include <stdio.h> 3 #include <stdlib.h> 4 http://joerg.li/category/services/ 5 int main(int argc, char **argv) 6 { 7 int a = 1; 8 http://www.jopspeech.com/category/services/ 9 printf("a = %i\n", a); 10 http://www.wearelondonmade.com/category/services/ 11 printf("&a = %p\n", &a); 12 13 return EXIT_SUCCESS; 14 https://waytowhatsnext.com/category/crypto/ 15 } 16 mimas$ http://www.iu-bloomington.com/category/crypto/ mimas$ mimas$ /usr/bin/gcc -std=iso9899:1999 -pedantic -pedantic-errors -fno-builtin https://komiya-dental.com/category/crypto/ -g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo.c mimas$ http://www-look-4.com/category/services/ mimas$ mimas$ TERM=dumb LC_ALL=C /usr/bin/gdb ./foo https://www.mktrade.fi/ruiskuvalu GNU gdb (Debian 10.1-2) 10.1.90.20210103-git g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o http://www.go-mk-websites.co.uk/crypto/namibia/ foo foo. g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso http://fishingnewsletters.co.uk/services/camping-equipment/ -o foo foo. g -m64 -O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo.
Issue no longer relevant since we switched to cmake and aren't using the libclamav.map