Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Fri, 2010-07-16 at 15:59 +0100, Julien Cristau wrote: > On Thu, Jul 1, 2010 at 10:01:27 +0200, Bastien ROUCARIES wrote: > > > tags 587227 + upstream > > tags 587227 + fixed-upstream > > thanks > > > > Upstream do a patch and commit will appear on svn this week end > > > What's up with this? Should we revert to 6.6.0.x with an epoched upload > in sid? Ping? Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Thu, Jul 1, 2010 at 10:01:27 +0200, Bastien ROUCARIES wrote: > tags 587227 + upstream > tags 587227 + fixed-upstream > thanks > > Upstream do a patch and commit will appear on svn this week end > What's up with this? Should we revert to 6.6.0.x with an epoched upload in sid? Cheers, Julien signature.asc Description: Digital signature
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
tags 587227 + upstream tags 587227 + fixed-upstream thanks Upstream do a patch and commit will appear on svn this week end Thank Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Mon, Jun 28, 2010 at 19:32:28 +0200, Bastien ROUCARIES wrote: > Do you know how to mangle name ? upstream whish to get a list of clear > name symbol > *sigh* I don't really have time for c++ 101 and libraries 101. Cheers, Julien signature.asc Description: Digital signature
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Mon, Jun 28, 2010 at 18:45:31 +0200, Bastien ROUCARIES wrote:
> On Mon, Jun 28, 2010 at 4:51 PM, Julien Cristau wrote:
> > On Mon, Jun 28, 2010 at 16:14:23 +0200, Bastien ROUCARIES wrote:
> >
> >> upstream does not seems how to use libtools in order to create a publi
> >> private list of symbols using the procedure described in
> >> http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=12841
> >>
> > Oh and fwiw libtool does not create a list. It takes a list (or regexp)
> > and ensures that only the matching symbols are exported. You can
> > achieve the same with a linker script or adding visibility attributes in
> > the source code. But neither of those prevent ABI breakage if public
> > functions or symbols change signature or are removed, which is what
> > happened here. The only way to prevent this is to either bump SONAME
> > when that happens, or not do those changes in the first place.
>
> yes but with a list of symbols publically exported we could use a
> script to detect change between version, and ask to bump soname in
> case of missmatch.
>
> We used with kind of stuff a long time ago, but upstream does not
> always bump soname saying it is a private symbols. We therefore ask to
> only export public symbols and they do not know how to use libtool
> facility. So if you post a patch, we could create a list and after a
> few iteration only export abi stable symbols.
>
You can get a basic list with:
$ objdump -T /usr/lib/libMagick++.so.3 | grep -v UND
For a demangled list:
$ objdump -T /usr/lib/libMagick++.so.3 | grep -v UND | \
awk '/Base/ { print $NF }' | c++filt
You can use this as input to a symbols file, see dpkg-gensymbols(1) and
deb-symbols(5).
e.g.:
$ echo 'libMagick++.so.3 libmagick++3 #MINVER#' > libmagick++3.symbols
$ objdump -T /usr/lib/libMagick++.so.3 | grep -v UND | \
awk '/Base/ { print $NF }'| c++filt | sed -e 's/.*/ (c++)&@Base 0/' \
>> libmagick++3.symbols
Then adjust for the unavoidable architecture differences. subsequent
builds of the package will fail if any of those symbols disappear (and
if any new ones appear, you should update the file (so that you'll
notice if they are removed again). You can do the same with the mangled
symbols if you prefer, just remove the c++filt step and the '(c++)' tag
from the symbols file.
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Mon, Jun 28, 2010 at 4:51 PM, Julien Cristau wrote: > On Mon, Jun 28, 2010 at 16:14:23 +0200, Bastien ROUCARIES wrote: > >> upstream does not seems how to use libtools in order to create a publi >> private list of symbols using the procedure described in >> http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=12841 >> > Oh and fwiw libtool does not create a list. It takes a list (or regexp) > and ensures that only the matching symbols are exported. You can > achieve the same with a linker script or adding visibility attributes in > the source code. But neither of those prevent ABI breakage if public > functions or symbols change signature or are removed, which is what > happened here. The only way to prevent this is to either bump SONAME > when that happens, or not do those changes in the first place. yes but with a list of symbols publically exported we could use a script to detect change between version, and ask to bump soname in case of missmatch. We used with kind of stuff a long time ago, but upstream does not always bump soname saying it is a private symbols. We therefore ask to only export public symbols and they do not know how to use libtool facility. So if you post a patch, we could create a list and after a few iteration only export abi stable symbols. Bastien > Cheers, > Julien > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCAAGBQJMKLcDAAoJEDEBgAUJBeQMGnAP/RL1vrqk31c1+e0N2sqh6+7R > EpzXe+NyTRCTR/fmvLE7L+VBcqI0SDMDjdbWHgzd848he7qmHF7Z2i3xyOsU9DEI > XZ+ejfA6n3YXyGpwtfpYDQAEtzuxEBiimxAJG6ZIK0FGtg67OwY0BOFPSTNAA77L > BrPK+umBoMSnyhJyvKdJORBbqrJPxe1tl5OE90Q7dA2v4hO9sGvtkilSMyNdbWSs > ASRCq69ET7a3PVkpZY/cWO9y+IaVRzlL0yrUo9FmSmyIQhdd4L64BMTr+AWUhJU7 > 6wKjqnghcj4IVnbOfViej/mrC0O1pvEnUNEuMyVsy/5wpa5vWZFzdPN4pXiANrWG > UI/S+0emQaOV7J+V4j/LwlycurgleMMBcN50yXrs49QccjuX0+FhxFrSpL2quDTh > A7JMz8yq5WHCJISn32k69IPBObWZHJz6HSY8+2j4QpozFJDs9G4pg3DYjRlsBTrN > HZRVi4WsKTG0R/oev7amDhhQ/unB4prkGbuBARTBfK17Ozo73ewbP3vjau5eusah > Y1jXbgr8hb+XiwaewuZBjLFssxePIJ7iFObeaUJX3ChP6vkOq7U7jHpgCjgZvWvy > DIG9RLIFnxgDpATbZu9rqCUgNl32YxNrD0GVAgow/A5k3CE7u2y04ZsFA4peanQO > ORwJ/7xf525ldWe6xC+5 > =jqks > -END PGP SIGNATURE- > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Mon, Jun 28, 2010 at 16:14:23 +0200, Bastien ROUCARIES wrote: > upstream does not seems how to use libtools in order to create a publi > private list of symbols using the procedure described in > http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=12841 > Oh and fwiw libtool does not create a list. It takes a list (or regexp) and ensures that only the matching symbols are exported. You can achieve the same with a linker script or adding visibility attributes in the source code. But neither of those prevent ABI breakage if public functions or symbols change signature or are removed, which is what happened here. The only way to prevent this is to either bump SONAME when that happens, or not do those changes in the first place. Cheers, Julien signature.asc Description: Digital signature
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Mon, Jun 28, 2010 at 16:14:23 +0200, Bastien ROUCARIES wrote: > Dear julian > > upstream does not seems how to use libtools in order to create a publi > private list of symbols using the procedure described in > http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=12841 > > I could not post a patch until a month (overwork) so if you beat me, > it will be really nice. > I don't know which of the 2000 or so symbols exported by libMagick++ are intended as public, and I don't really feel like going through the list and make wild guesses. Cheers, Julien signature.asc Description: Digital signature
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
Dear julian
upstream does not seems how to use libtools in order to create a publi
private list of symbols using the procedure described in
http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=12841
I could not post a patch until a month (overwork) so if you beat me,
it will be really nice.
Bastien
On Sat, Jun 26, 2010 at 2:50 PM, Julien Cristau wrote:
> On Sat, Jun 26, 2010 at 13:10:26 +0100, Julien Cristau wrote:
>
>> Package: libmagick++3
>> Version: 7:6.6.2.6-1
>> Severity: serious
>>
>> libMagick++.so.3 in squeeze exports a _ZN6Magick5Image8contrastEj
>> symbol. The version in sid doesn't. This breaks (at least)
>> python-imagemagick. Please be more careful about ABI compatibility...
>>
> So on amd64 I count 130 removed symbols. It's likely there are others
> that only affect 32bit archs. Checking that kind of things should be
> the *first* thing you do on a new upstream release, especially when you
> know upstream is unable to maintain their ABI properly. And it's not
> like these things are well-hidden, a debdiff shows e.g. for
> lib/Magick++/Drawable.h:
>
> @@ -2055,8 +2055,8 @@
> class MagickDLLDecl DrawableViewbox : public DrawableBase
> {
> public:
> - DrawableViewbox(unsigned long x1_, unsigned long y1_,
> - unsigned long x2_, unsigned long y2_)
> + DrawableViewbox(ssize_t x1_, ssize_t y1_,
> + ssize_t x2_, ssize_t y2_)
> : _x1(x1_),
> _y1(y1_),
> _x2(x2_),
>
> which is quite trivially not going to fly.
>
> Cheers,
> Julien
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJMJfd+AAoJEDEBgAUJBeQMmnAP/3sCUJqNMIEhXisCzSRXusnR
> NHDAE2yTZPmOxs50up3bpAsex7AdkJZr9DscVvpsOU3rXL4Sn+5QJ1QoaSl4V9oy
> iJ4GXW52C43kbZhEMhj7U6glvEAizehfxlnY8tLCfsxrx0fzhCg+KObGqienlEf+
> XMxFk3rdUSE7xYka5pD4eIwP/oHmcyRkboo/3k+NdKR2Eqo1Fjz6ma/nLvCiZIoH
> 74R8GCyLIUl7gBjEw6eMPxye8w9rJS/jol+9Oe188KN6n1uwTQchKuSt/87/HKwK
> XdMfAETJd1Q56n688iQo920ow8k6XlRZc3VBG76TRu/xEL+sWn8qvF6XTUA5piuN
> NYaNGO7kfkdpYx4lOBPrhJPZSRJonnG4vZp94F/w03Clfvr7974OIKdHc/dl/Qlz
> fIuQ7MgF4ZfxIuHnYDJ43uckbydknp5p0vGZEaPM65j+GwpDuOYcdPNb2n3+kgs2
> gUlwqo674F/hVuVEly9lsSifIszNfKzEU1Vk4vDONKXUADcV170Qpntr5PqsjgWQ
> joqLFQ21YLQHHj1QbhHcpM+9UtIyB6lvWhymfKbdWREksnSlCUDI+2hx9iBFvivH
> tUsTUlJ5D3d7AdFW96+569QZ+6TJ+b+UhF1xW++NbvpBs1tzuOtfcSrHjgl6q9FN
> MrQ3DikB/hR3dTuAUpTC
> =V6qy
> -END PGP SIGNATURE-
>
>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
I have open a new bug about the reccurent problem. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587393 Please add comment on upstream forum. Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
On Sat, Jun 26, 2010 at 13:10:26 +0100, Julien Cristau wrote:
> Package: libmagick++3
> Version: 7:6.6.2.6-1
> Severity: serious
>
> libMagick++.so.3 in squeeze exports a _ZN6Magick5Image8contrastEj
> symbol. The version in sid doesn't. This breaks (at least)
> python-imagemagick. Please be more careful about ABI compatibility...
>
So on amd64 I count 130 removed symbols. It's likely there are others
that only affect 32bit archs. Checking that kind of things should be
the *first* thing you do on a new upstream release, especially when you
know upstream is unable to maintain their ABI properly. And it's not
like these things are well-hidden, a debdiff shows e.g. for
lib/Magick++/Drawable.h:
@@ -2055,8 +2055,8 @@
class MagickDLLDecl DrawableViewbox : public DrawableBase
{
public:
- DrawableViewbox(unsigned long x1_, unsigned long y1_,
- unsigned long x2_, unsigned long y2_)
+ DrawableViewbox(ssize_t x1_, ssize_t y1_,
+ ssize_t x2_, ssize_t y2_)
: _x1(x1_),
_y1(y1_),
_x2(x2_),
which is quite trivially not going to fly.
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#587227: libmagick++3: ABI breakage without SONAME change (yet again)
Package: libmagick++3 Version: 7:6.6.2.6-1 Severity: serious libMagick++.so.3 in squeeze exports a _ZN6Magick5Image8contrastEj symbol. The version in sid doesn't. This breaks (at least) python-imagemagick. Please be more careful about ABI compatibility... Cheers, Julien signature.asc Description: Digital signature
