Mailing List Archive

nicolas dumont wrote:
> Is there a way in my Makefile or elsewhere to have the libclamunrar
> directly called
> inside my binary without modifying the call to
> lt_dlopenext("libclamunrar_iface") ?


Your Makefile? Where is it?

-aCaB
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

2009/3/25 aCaB <acabng@digitalfuture.it>

> nicolas dumont wrote:
> > Is there a way in my Makefile or elsewhere to have the libclamunrar
> > directly called
> > inside my binary without modifying the call to
> > lt_dlopenext("libclamunrar_iface") ?
>
>
> Your Makefile? Where is it?
>

I've developped a small daemon in order to do the initialization of
libclamav and load the database. Then I am able to answer to SCAN messages.
So, in order to compile my .c files I have a small Makefile.

And in my makefile, for clamav-0.94.2 I had added the following lines :
LDADD += ${CLAMDIR}/libclamav/.libs/libclamav.a
LDADD += ${CLAMDIR}/libclamunrar_iface/.libs/libclamunrar_iface.a
LDADD += ${CLAMDIR}/libclamunrar/.libs/libclamunrar.a
LDADD += -lz
LDADD += -lbz2

But, with clamav-0.95, it's not enough to have the unrar functions
available.

How can I do, If I want to have libclamunrar included in my daemon ?
I don't want to have the libclamunrar separated from my binary

BR,
Nicolas Dumont

>
> -aCaB
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

nicolas dumont wrote:
> I've developped a small daemon in order to do the initialization of
> libclamav and load the database. Then I am able to answer to SCAN messages.
> So, in order to compile my .c files I have a small Makefile.
>
> And in my makefile, for clamav-0.94.2 I had added the following lines :
> LDADD += ${CLAMDIR}/libclamav/.libs/libclamav.a
> LDADD += ${CLAMDIR}/libclamunrar_iface/.libs/libclamunrar_iface.a
> LDADD += ${CLAMDIR}/libclamunrar/.libs/libclamunrar.a
> LDADD += -lz
> LDADD += -lbz2
>
> But, with clamav-0.95, it's not enough to have the unrar functions
> available.
>
> How can I do, If I want to have libclamunrar included in my daemon ?
> I don't want to have the libclamunrar separated from my binary

Hi nicolas dumont,
You are clearly doing it wrong.

Please provide a link to the full source code and, when time permits, i
can see what's wrong and possibly offer a complete patch.

-aCaB

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

I'm sorry if I'm not enough clear of what I want to do.

I just want to have the unpacked RAR files feature available in my binary
without
loading separatly the library libclamunrar_iface.a that you provided in the
clamav-0.95.tar.gz

BR,
Nicolas Dumont.

2009/3/25 aCaB <acabng@digitalfuture.it>

> nicolas dumont wrote:
> > I've developped a small daemon in order to do the initialization of
> > libclamav and load the database. Then I am able to answer to SCAN
> messages.
> > So, in order to compile my .c files I have a small Makefile.
> >
> > And in my makefile, for clamav-0.94.2 I had added the following lines :
> > LDADD += ${CLAMDIR}/libclamav/.libs/libclamav.a
> > LDADD +=
> ${CLAMDIR}/libclamunrar_iface/.libs/libclamunrar_iface.a
> > LDADD += ${CLAMDIR}/libclamunrar/.libs/libclamunrar.a
> > LDADD += -lz
> > LDADD += -lbz2
> >
> > But, with clamav-0.95, it's not enough to have the unrar functions
> > available.
> >
> > How can I do, If I want to have libclamunrar included in my daemon ?
> > I don't want to have the libclamunrar separated from my binary
>
> Hi nicolas dumont,
> You are clearly doing it wrong.
>
> Please provide a link to the full source code and, when time permits, i
> can see what's wrong and possibly offer a complete patch.
>
> -aCaB
>
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

nicolas dumont wrote:
> Hello,
>
> I am using clamav-0.95 with my own daemon that use libclamav
>
> During the initialization I have the message :
> LibClamAV Warning: Cannot dlopen: file not found - unrar support unavailable
>
> I would like to link my daemon with the libclamunrar_iface.a and libclamunrar.a
> in order to have all libraries inside my binary.
>
> Is there a way in my Makefile or elsewhere to have the libclamunrar
> directly called
> inside my binary without modifying the call to
> lt_dlopenext("libclamunrar_iface") ?
>
> Best regards,
> Nicolas Dumont.
>

Hi Nicholas,

I am also compiling ClamAV into a library and opening it with a dlopen()
call. The technique I use is:

/configure
make

I then merge together the different ClamAV libs using this command:

ld -shared -o clamav.lib clamav-0.94.2/libclamav/.libs/libclamav.a
clamav-0.94.2/libclamunrar_iface/.libs/libclamunrar_iface.a
clamav-0.94.2/libclamunrar/.libs/libclamunrar.a -lbz2 -lgmp -lpthread -lz

Which creates a file called clamav.lib that can be passed to dlopen().

There are a couple of notes. Which libraries you dynamically link
against when using ld will vary depending on your platform and how
ClamAV configures itself. For example, on my system I don't actually
link against pthread specifically because I know the program I'm using
is already linked against the pthread library. On Cent OS 4/Red Hat
Enterprise 4 specifically, I need to pass the --disable-zlib-vcheck
parameter to configure and I need to manually edit the libclamav
makefiles to pass -O1 instead of -O2 to gcc or all of the free() calls
will be optimized away inside the cl_free() function. See this bug for
details:

https://bugzilla.redhat.com/show_bug.cgi?id=490253

If anyone knows of a better way to do this, or finds any problems with
using ClamAV this way, please let me know...

Ladar


_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Ladar Levison wrote:

> I then merge together the different ClamAV libs using this command:
>
> ld -shared -o clamav.lib clamav-0.94.2/libclamav/.libs/libclamav.a
> clamav-0.94.2/libclamunrar_iface/.libs/libclamunrar_iface.a
> clamav-0.94.2/libclamunrar/.libs/libclamunrar.a -lbz2 -lgmp -lpthread -lz

I suspect that this may break on AMD64. It's more picky about PIC/non-PIC code
(no pun intended), attempt to link objects from .a into .so often fails.

Eugene

Eugene Crosser wrote:
> I suspect that this may break on AMD64. It's more picky about PIC/non-PIC code
> (no pun intended), attempt to link objects from .a into .so often fails.
>

I haven't tested this method on any AMD64 servers, but it wouldn't
surprise if you were right. When I tried using this method on a Cent OS
5 system, I had to link 1-2 or other libraries before dlopen() would
accept it.

Any thoughts on a better way of accomplishing the same task? I like to
combine all of the f/oss libraries my daemon uses into a single library
(clamav, openssl, memcached, etc). It makes deployments easier
(executable, f/oss library and config file).

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Ladar Levison wrote:
> Eugene Crosser wrote:
>> I suspect that this may break on AMD64. It's more picky about PIC/non-PIC code
>> (no pun intended), attempt to link objects from .a into .so often fails.
>>
>
> I haven't tested this method on any AMD64 servers, but it wouldn't
> surprise if you were right. When I tried using this method on a Cent OS
> 5 system, I had to link 1-2 or other libraries before dlopen() would
> accept it.
>
> Any thoughts on a better way of accomplishing the same task? I like to
> combine all of the f/oss libraries my daemon uses into a single library
> (clamav, openssl, memcached, etc). It makes deployments easier
> (executable, f/oss library and config file).

Technically, you have to ensure that all the code that is going into your shared
object is compiled with -fPIC. If the libraries where built with
automake/libtool, the .so's are (obviously) made of PIC objects, while .a's are
likely not.

If you use automake/libtool to build *your* project, you specify library
descriptors (.la files) in the build instructions in Makefile.am, and the
infrastructure will do "The Right Thing" for you, taking either .a or .so
libraries depending on your intended target. I think that the .so's are still
dynamically linked in this case, and I am not sure if you can forcibly clump all
the objects into a single .so. On the other hand, maybe you don't need.

Sorry for being so vague. Automake and libtool documentation is where you can
find definite answers.

Eugene