steve at lobefin
Nov 20, 2007, 3:03 PM
Post #4 of 5
(294 views)
Permalink
|
|
Re: symbol visibilty, public API, and internal function useage
[In reply to]
|
|
On Tue, Nov 20, 2007 at 09:59:21PM +0200, Török Edwin said:
> Stephen Gran wrote:
> > Hi all,
> >
> > So I've been thinking about how to reduce the breakage that occasionally
> > happens to other bits of software on upgrades of libclamav, and I think
> > I've come up with something that might be of some use. libtool lets you
> > use a version script to (on platforms that support it) hide symbols from
> > being globally visible and version those that are.
[...]
> This reminds me of https://wwws.clamav.net/bugzilla/show_bug.cgi?id=272
Yes, that's exactly the same issue.
> > It also
> > doesn't actually help with API/ABI changing modifications in the public
> > API itself -
> Ulrich Drepper says in his DSO howto
> (http://people.redhat.com/drepper/dsohowto.pdf) that API/ABI stability
> can be maintained via versioning. But that is stuff for post 1.0 IMHO.
Agreed. I just meant that symbol visibilty doesn't actually force you
guys to maintain a stable public API - you can still change that every
release if you want. It just makes it easier to break the private
functions as often as you want :)
> Did any breakage occur due to changes in cli_* functions? People should
> really not use those directly.
I think so. I can't remember the details now, but when we did the
libclamav1 -> libclamav2 transition in Debian, there were a few
applications that either used functions not in the public headers, or
messed about with the internals of private structs. We all know that's
bad behavior on the part of those applications - I'm just trying to
force them to use the interface that they're given.
> > My personal preference is 2. It incurs some on disk and memory
> > overhead, as these symbols will be loaded once for each application,
> > rather than the normal shared library memory saving techniques. That
> > being said, it is the simplest to manage, and is the most effective at
> > making sure other applications do not link to private functions within
> > the clamav suite that change between releases.
>
> Actually if we have export maps the size of the .so will be cut down, so
> maybe it would compensate for it.
That's a point I hadn't considered. You may be right. I sort of feel
that on most hardware capable of running clamav, we're unlikely to
notice a real difference with any of the proposed changes, but I'm
generally in favor of efficiency.
> > Ok, so long preamble over.
> >
> > version script:
> > [.....]
> > vba56_dir_read;
> > vba_decompress;
>
> I guess this is only used by sigtool. I wouldn't mind linking sigtool
> statically with libclamav, it is not a tool used on a day-by-day basis
> by end-users.
> I think if you don't consider sigtool you can significantly shorten this
> list.
I got a half dozen from each app, unfortunately. The milter is a heavy
user of several output functions as well as cli_malloc/realloc and
friends, clamd uses a bunch of tmpfile related functions, and so on. I
could make up a list of what each app uses if you like, but it's trivial
to discover. Just make a version script where cl_* is the only thing in
global: and watch what breaks :)
> Besides if people see this list in an export map they'll start using it,
> because they'll consider it public :(
No more than they do now, I'm sorry to say. I am viewing this as a step
to reducing what other projects are _able_ to use from clamav. This
will mean some changes in clamav as well, though.
> I was also thinking of using -fvisibility feature of gcc to hide
> internals functions, which has the nice benefit of
> avoiding an indirect call (usually symbols not declared static need an
> extra indirection due to -fPIC).
> However I didn't like the way -fvisibility has to be used.
> I either have to explicitly declare the visibility of all functions
> exported, or declare visibility on all functions being hidden.
> Even on functions declared as extern! Sure, we could do an EXTERN macro
> that also adds the visibility attribute ...
Yes, that's why I decided on the version script approach. I find
-fvisibility painful to use well.
> However linker export maps can be implemented independently of
> -fivisibility :)
Very true.
> Yes it would be nice to narrow down the list to this.
> Does this work with GNU ld only? (it is supposed to work with Solaris's
> ld too)
As far as I know, it work on at least Solaris, Linux and the BSDs.
I may be wrong, though - I tend not to spend a lot of time working on
platforms besides linux these days. At any rate, it'll be more than what
there is now, and people will generally be compiling 3rd party software
against clamav on one of those platforms anyway. Someone who wants to
only build an application against libclamav private functions on RiscOS
is, well, probably beyond help anyway.
Thanks,
--
--------------------------------------------------------------------------
| Stephen Gran | In the long run we are all dead. -- |
| steve[at]lobefin.net | John Maynard Keynes |
| http://www.lobefin.net/~steve | |
--------------------------------------------------------------------------
|
signature.asc
