Bugzilla – Bug 11124
A couple of clamdscan compilation issues (from the ClamAV user list)
Last modified: 2018-10-31 09:56:33 EDT
Notes on cross compiling clamav-0.98.4 for freescale based arm board Down load clamav-0.98.4.tar.gz tar xvzf clamav-0.98.4.tar.gz mkdir clamav_install_dir created exports for cross compiler so configure finds the right stuff, e.g.; PATH, ARCH, CFLAGS, LDFLAGS, CROSS_COMPILE, CC, AR, LD. cd clamav-0.98.4 This is the configure line I finally got to work: ./configure --build=i686-host-linux-gnu --host=arm-fsl-linux-gnueabi --with-openssl=/<built rootfs dir>/usr --with-zlib=/<built rootfs dir/usr --includedir=/<built rootfs dir>/usr/include --libdir=/<built rootfs dir>/usr/lib --with-gnu-ld --with-sysroot=/<built rootfs dir> - -prefix=/<my clamav build dir>/clamav_install_dir --disable-clamav --enable-unrar=no In clamav-0.98.4/clamdscan/proto.c, sockaddr_un was unknown, so made the following change: #ifndef _WIN32 // extern struct sockaddr_un nixsock; struct sockaddr_in nixsock; #endif20140924 make make install Note: for make install, library files are getting installed to <build rootfs dir> so you need write permssions here. It would be nice if --prefix would control where the lib files get installed. It's handy to be able to build in isolation and cherry pick what you need. Binaries are in clamav_install_dir. Copied binaries, libs, etc and daily.cvd to my target. On running any of the binaries I get the following warning, which I haven't been able to get rid of, even when using the configure flag --enable-unrar=no. LibClamAV Warning: Cannot dlopen libclamunrar_iface: file not found - unrar support unavailable But other than this, everything appears to work. Successfully scanning files! Yeah! Note: <built rootfs dir> this is my cross compiled root file system directory. In my case it's a, previously built(cross-compiled), typical debian based, directory structure, e.g.: /bin, /sbin, /lib, /usr/lib, /usr/include. /lib, /usr/lib and /usr/include contain all dependent shared libraries and include files needed. (sorry if this is getting pedantic, but if cross compilation is new to you, this is a pre-requisit.) Cheers, J. Unsubscribe from our commercial electronic messages. http://supportcentral.ge.com/esurvey/takesurvey.asp?p=17778&d=3834102 Désabonner de nos messages électroniques commerciaux. http://supportcentral.ge.com/esurvey/takesurvey.asp?p=17778&d=3839563 _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml Bernd Kuhls <bernd.kuhls@t-online.de> Sep 28 (1 day ago) to clamav-users "Mclean, John (GE Energy Management)" <JohnD.Mclean@ge.com> wrote in news:831B11E079465943A5793894E6B32AC80B7069AC@CINURCNA24.e2k.ad.ge.com: > In clamav-0.98.4/clamdscan/proto.c, sockaddr_un was unknown, so made the following change: Hi, you could also try to add #include <sys/un.h> to clamdscan/proto.c. This fixes a similar bug here: proto.c: In function ‘dconnect’: proto.c:86:67: error: invalid application of ‘sizeof’ to incomplete type ‘struct sockaddr_un’ if (connect(sockd, (struct sockaddr *)&nixsock, sizeof(nixsock)) == 0) Regards, Bernd _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
The lack of the <sys/un.h> include also causes a compile fail in 0.98.7 in HP-UX 11.11. I added a #include for it above the arpa/inet.h include and the problem was resolved. Does sys/un.h need to be checked in configure and use a HAVE_SYS_UN_H define? Should it be confined to certain platforms like Steve's ARM and my PA-RISC? I've been hunting but haven't yet identified why this isn't a problem on Linux.
Reviewing this bug: <sys/un.h> is now in clamdscan/proto.c. I tested './configure --prefix=/home/me/myprefix'. My /home/me/myprelib/lib is populated as directed by --prefix, but I did not use --libdir, which appears to override --prefix for the libraries. So I think all that remains is the issue of opening libclamunrar_iface. Not sure if this issue is the result of cross-compiling, or if it is due to missing dynamic linking functionality in you target platform.
Does not appear to be much interest in this issue. Due to that we will be closing this ticket as wont fix. If there is still interest from the community, please reply and let us know.