Bug 11124 - A couple of clamdscan compilation issues (from the ClamAV user list)
A couple of clamdscan compilation issues (from the ClamAV user list)
Status: RESOLVED WONTFIX
Product: ClamAV
Classification: ClamAV
Component: other
0.98.4
x86_64 GNU/Linux
: P3 normal
: old_bug_triage
Assigned To: ClamAV team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-29 11:21 EDT by Steven Morgan
Modified: 2018-10-31 09:56 EDT (History)
4 users (show)

See Also:
QA Contact:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steven Morgan 2014-09-29 11:21:50 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
Comment 1 Michael Pelletier 2015-07-01 16:23:55 EDT
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.
Comment 2 Steven Morgan 2015-10-22 18:12:01 EDT
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.
Comment 3 Joe McGrath 2018-10-31 09:56:33 EDT
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.