Missing symbols between ImageMagick releases

[naoliv]

Hi!

On the latest Debian package we have added some infrastructure to deal with symbols exported by the ImageMagick libraries.
One problem that we saw is that some symbols just disappear (and without a SONAME change).
For example, DecryptImage@Base and EncryptImage@Base that were exported by ImageMagick 6.4.8-0 aren't available now on version 6.4.8-3

Another example (that is fixed on 6.4.8-3):
DrawPrimitive@Base was available in 6.4.0-1, then disappeared with 6.4.5-4 and is now available again on 6.4.8-3

Adding new symbols without changing the SONAME is OK (like PasskeyDecipherImage@Base and PasskeyEncipherImage@Base), but removing symbols can break programs depending on them (and less important to the users, it will break the building process of our ImageMagick Debian packages).

A solution would be to add back the symbols again or to bump the SONAME, if a symbols really needs to be removed.

Thank you!

[magick]

We do not bump the library version if we remove a non-public method. Since C does not really have a concept of public and private, we define public as any method defined here: http://magick.imagemagick.org/script/magick-wand.php and here: http://magick.imagemagick.org/script/magick-core.php. If users use any private methods (those not defined as public in the web pages-- they do so at their own risk because the method signatures may change or they may be removed. On occasion we get a request to promote a private method to the public API so ensure its available and that it will not change (e.g. DrawPrimitive). Given the discussion here, are there any methods we overlooked? That is did we remove or change a public API method that we are unaware of? Also are there private API methods that you would like promoted to a public method?

To be on the safe side-- we will bump the SO version for the next point release.

[naoliv]

Hi!

Talking with Daniel Kobras (who also co-maintains ImageMagick on Debian), it seems that you are exporting symbols that should be kept privately:

> So are they exporting private symbols? (and that is why
> dpkg-gensymbols is saying that some have disappeared?)

Correct. There's nothing wrong with the way you're calling
dpkg-gensymbols. It's just that the library advertises symbols that it
shouldn't. As IM uses libtool, I think the best answer in this case is
to make use of its feature to hide all symbols unless explicitly listed
as public. (The symbols are still usable from within the library itself.
It'll get tricky if some symbols ought to be available to coders in a
modular build, but not to applications, though.) To make use of the
feature, one needs to create a symbols file like magick-public.sym or
wand-public.sym, listing public symbols one at a line. It is passed to
libtool via LDFLAGS using option -export-symbols, eg.

libwand_la_LDFLAGS = (...) -export-symbols wand-public.sym

The symbols file needs to be updated as API functions are added and
removed.

That can explain why our Debian tool (dpkg-gensymbols) keep catching changes in the symbols between ImageMagick releases.

[magick]

The C language design, as stated, does not have a formal method to declare public vs. private other than with 'static'. Static works fine if the method is used within the module that it is declared but not if the method is called from several source modules. MagickCore and MagickWand declares close to 1600 methods and a great majority of them are used internally with only a couple hundred considered as public for general use. Currently we declare the general use methods in the ImageMagick web pages. However, if you have a better way we will consider changing our current methods. Perhaps it will be as simple as including the exported symbol file you discussed. If so, clue us in on how to create it and use it and we will work toward getting the changes into the next release.

[broucaries]

According to libtool manual it is simple:
>`-export-symbols symfile'
> Tells the linker to export only the symbols listed in symfile. The symbol file should end in `.sym' and must contain the name of one symbol per line. This option > has no effect on some platforms. By default all symbols are exported.

I see also some project doing something better they document using xml file and created .sym file using xslt script

Regards

bastien

[naoliv]

Hi!

I still see 2236 symbols exported by libmagick++, 1170 by libmagickcore and 624 by libmagickwand (using SVN revision 13763).

[magick]

We created MagickCore.sym and MagickWand.sym with all the exported symbols and ImageMagick failed to execute with this exception:

• convert logo: logo.png
  convert: unable to load module `/usr/local/lib/ImageMagick-6.4.8/modules-Q16/coders/gif.la': file not found @ module.c/OpenModule/1134.
  convert: no decode delegate for this image format `LOGO' @ blob.c/BlobToImage/340.
  convert: missing an image filename `logo.png' @ convert.c/ConvertImageCommand/2756.

Not sure why lt_dlopen() is failing and returning the 'file not found' exception.

[broucaries]

Any news of this effort ?

A new user of debian encounter a problem with symbols see viewtopic.php?f=2&t=15311

Regards

bastien

[naoliv]

Any news of this effort ?

A new user of debian encounter a problem with symbols see viewtopic.php?f=2&t=15311

Well... actually I am not a new user of Debian

[magick]

ImageMagick 6.5.9-0 resolves this problem. Is is scheduled for release this week.

[broucaries]

Do you mean the so bump or the more general problem about sym file

[magick]

We will bump the SO version. We do not have a Debian system so we're clueless on how to manage symbols that would make Debian happy and still work for all the Linux / Solaris distributions. If you provide us with patches, scripts, and a detailed explanation that will work under Fedora, Redhat, or CentOS we will consider incorporating it in future ImageMagick releases.

[broucaries]

The export-symbols of libtool could be used on all plateform were libtool exist

[broucaries]

Any news of the effort to define a public private abi using libtool ?

Another problem of symbols file without so bump
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=564123

Please try to use the libtool mecanism

Thank you bastien

[magick]

We do not know how to properly utilize libtool for public / private symbols. If you or one of your users submit patches against the current ImageMagick release, we will make sure they get into the next release of ImageMagick.