|
Home > Archive > Debian Developers > July 2005 > aspell upgrade woes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
aspell upgrade woes
|
|
| Thomas Bushnell BSG 2005-07-20, 2:49 am |
|
So aspell changed the library name to libaspell15c2, which breaks all
the existing packages that use libaspell.
Was this really an ABI change in libaspell? If not, there was no
reason to make the change as I understand it. Were high-severity bugs
filed on all the packages that depend on the library, requesting
recompiles?
My understanding was that this upgrade would *not* normally change
library package names, so I'm wondering why this one did. The aspell
changelog doesn't contain anything illuminating.
Thomas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2005-07-20, 2:49 am |
| Brian Nelson <pyro@debian.org> writes:
> Thomas Bushnell BSG <tb@becket.net> writes:
>
>
> Uhh...
>
> aspell (0.60.3-2) unstable; urgency=low
>
> * debian/control: renamed libaspell15 to libaspell15c2 for the GCC 4.0
> ABI change transition
So, to repeat, since apparently my questions were not clear enough:
1: Was there an ABI change in libaspell15 itself? (In the
*programming* *source-level* interface?) Which functions interfaces
changed, and why were the changes not noted in the changelog?
2: Were high severity bugs filed on all the packages that depend on
the library, requesting recompiles?
Thomas
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2005-07-20, 2:49 am |
| Brian Nelson <pyro@debian.org> writes:
[helpful stuff]
Thanks, I understand now.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian Nelson 2005-07-20, 2:49 am |
| Thomas Bushnell BSG <tb@becket.net> writes:
> Brian Nelson <pyro@debian.org> writes:
>
> bugs
>
> So, to repeat, since apparently my questions were not clear enough:
>
> 1: Was there an ABI change in libaspell15 itself? (In the
> *programming* *source-level* interface?) Which functions interfaces
> changed, and why were the changes not noted in the changelog?
Uhhhhh... no...
http://lists.debian.org/debian-deve...7/msg00001.html
It's a C++ library and the ABI changed due to being compiled with GCC
4.0.
[Actually, although it's written in C++, AFAIK it only exports a C
interface so the transition may not have been necessary. I only
realized this yesterday though and I'm not entirely sure a
non-transition would be safe.]
> 2: Were high severity bugs filed on all the packages that depend on
> the library, requesting recompiles?
Not yet, presumably because a huge portion of unstable needs to undergo
the transition anyway.
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian Nelson 2005-07-20, 2:49 am |
| Thomas Bushnell BSG <tb@becket.net> writes:
> So aspell changed the library name to libaspell15c2, which breaks all
> the existing packages that use libaspell.
>
> Was this really an ABI change in libaspell? If not, there was no
> reason to make the change as I understand it. Were high-severity bugs
> filed on all the packages that depend on the library, requesting
> recompiles?
>
> My understanding was that this upgrade would *not* normally change
> library package names, so I'm wondering why this one did. The aspell
> changelog doesn't contain anything illuminating.
Uhh...
aspell (0.60.3-2) unstable; urgency=low
* debian/control: renamed libaspell15 to libaspell15c2 for the GCC 4.0
ABI change transition
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-07-20, 2:49 am |
| On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
> It's a C++ library and the ABI changed due to being compiled with GCC
> 4.0.
> [Actually, although it's written in C++, AFAIK it only exports a C
> interface so the transition may not have been necessary. I only
> realized this yesterday though and I'm not entirely sure a
> non-transition would be safe.]
Heh. I've just confirmed this...
As with libGLU, libaspell is used in enough places that there's a definite
benefit to not breaking package compatibility unnecessarily. Since
libaspell15c2's shlibs refer to "libaspell15c2 (>= 0.60)", the only way to
provide full compatibility is with two real packages. I would suggest
restoring libaspell15, and creating a dummy libaspell15c2 package that
depends on libaspell15 and can be dropped once everything has been rebuilt
to use libaspell15 again; that would minimize the disruption caused by the
flip-flopping of the lib name.
Brian, if you agree, I'm happy to prepare a patch.
Cheers,
--
Steve Langasek
postmodern programmer
| |
| Brian Nelson 2005-07-20, 2:49 am |
| Steve Langasek <vorlon@debian.org> writes:
> On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
>
>
> Heh. I've just confirmed this...
>
> As with libGLU, libaspell is used in enough places that there's a
> definite benefit to not breaking package compatibility unnecessarily.
> Since libaspell15c2's shlibs refer to "libaspell15c2 (>= 0.60)", the
> only way to provide full compatibility is with two real packages. I
> would suggest restoring libaspell15, and creating a dummy
> libaspell15c2 package that depends on libaspell15 and can be dropped
> once everything has been rebuilt to use libaspell15 again; that would
> minimize the disruption caused by the flip-flopping of the lib name.
>
> Brian, if you agree, I'm happy to prepare a patch.
Reintroducing the libaspell15 could cause problems with /usr/bin/aspell,
since it actually goes outside the C API of libaspell and uses C++
linkage to some symbols. I "fixed" this bug (#307481) by making
aspell-bin (or now just aspell) depend on the Source-Version of
libaspell.
However, that fix is not in the stable package of aspell. In stable,
aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade
of just libaspell15 would break aspell-bin. I suppose I could make the
new libaspell15 conflict with the old aspell-bin, but that's rather
clumsy and could make upgrades even more awkward.
I'm not sure what the best thing to do would be. I'm sort of inclined
to just stick with the transitioned libaspell15c2...
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-20, 2:49 am |
| Brian Nelson <pyro@debian.org> writes:
> Steve Langasek <vorlon@debian.org> writes:
>
Actualy, since aspell FTBFS and libaspell15c2 was never in the archive
for all archs there shouldn't be any package linked against it. The
transition rules said to wait before uploading rdepends. This
obviously needs to be checked.
Also, all sources should duild-depend on the new aspell or some buildd
will use the libaspell15c2 instead and still get the 'broken' depeneds
entry and delay removing libaspell15c2.
So I would say just drop libaspell15c and reupload anything that was
already wrongfully uploaded again.
[vbcol=seagreen]
> Reintroducing the libaspell15 could cause problems with /usr/bin/aspell,
> since it actually goes outside the C API of libaspell and uses C++
> linkage to some symbols. I "fixed" this bug (#307481) by making
> aspell-bin (or now just aspell) depend on the Source-Version of
> libaspell.
>
> However, that fix is not in the stable package of aspell. In stable,
> aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade
> of just libaspell15 would break aspell-bin. I suppose I could make the
> new libaspell15 conflict with the old aspell-bin, but that's rather
> clumsy and could make upgrades even more awkward.
Why? This is exactly what a versioned conflict is for. The packages
have to be upgraded as pair and apt/dpkg will hapily do that. Having
libaspell15c2 conflict libaspell15 makes it no easier than having
libaspell15 conflict the old aspell-bin.
> I'm not sure what the best thing to do would be. I'm sort of inclined
> to just stick with the transitioned libaspell15c2...
Going back to libaspell unbreaks a bunch of rdepends and means aspell
can go into sarge on it's own, without waiting for the rats tail to
get transitioned as well. I think that is well worth it.
My 2 cents,
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Ron Johnson 2005-07-20, 7:54 am |
| On Wed, 2005-07-20 at 09:52 +0200, Goswin von Brederlow wrote:
> Brian Nelson <pyro@debian.org> writes:
>
[snip][vbcol=seagreen]
> So I would say just drop libaspell15c and reupload anything that was
> already wrongfully uploaded again.
What does that do to people who have already installed libaspell15c2,
and are in the middle of the cut-over?
[snip]
--
Ron Johnson <ron.l.johnson@cox.net>
| |
| Goswin von Brederlow 2005-07-20, 7:54 am |
| Ron Johnson <ron.l.johnson@cox.net> writes:
> On Wed, 2005-07-20 at 09:52 +0200, Goswin von Brederlow wrote:
> [snip]
>
> What does that do to people who have already installed libaspell15c2,
> and are in the middle of the cut-over?
>
> [snip]
They get the libaspell back when they upgrade aspell-bin.
Same thing that happened that made them get libaspell15c2.
amd64:~% apt-cache rdepends libaspell15c2
W: Unable to locate package libaspell15c2
Nothing happens on amd64, alpha or ia64.
i386:~% apt-cache rdepends libaspell15c2
libaspell15c2
Reverse Depends:
aspell-pl
logjam
libtext-aspell-perl
libpspell-dev
libgtkspell0
libenchant1c2
libaspell-dev
gedit
gaim
balsa
aspell
aspell
All those would need a quick reupload.
The reason I'm against introducing a dummy package is that it will
cause those packages listed above to depend on different packages
(libaspell15 vs libaspell15c2) depending on the architecture. Without
dummy package they are forced to make a new upload at the proper time.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nathanael Nerode 2005-07-20, 7:54 am |
| pyro@debian.org wrote:
>[Actually, although it's written in C++, AFAIK it only exports a C
>interface so the transition may not have been necessary. I only
>realized this yesterday though and I'm not entirely sure a
>non-transition would be safe.]
Non-transition is safe and desirable if all the C++ libraries it depends on use
versioned symbols. libstdc++ does, and apparently that's the only one libaspell
depends on. So indeed no transition is necessary or desirable for libaspell.
(If a C++-written library exporting only a C interface depended on a C++ library which
had unversioned symbols (whew!), then a transition might be neccesary, but I'm not
sure; if that case ever comes up, it's worth extra analysis.)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Nusinow 2005-07-20, 5:58 pm |
| On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
> Uhhhhh... no...
>
> http://lists.debian.org/debian-deve...7/msg00001.html
>
> It's a C++ library and the ABI changed due to being compiled with GCC
> 4.0.
>
> [Actually, although it's written in C++, AFAIK it only exports a C
> interface so the transition may not have been necessary. I only
> realized this yesterday though and I'm not entirely sure a
> non-transition would be safe.]
Christ, not another one. Is there any sort of automated way that we can
check for these sorts of libraries before messing things up again? I won't
be doing it again for libGLU obviously, but some sort of script or
large-scale automated check of the archive would potentially go a long way.
- David Nusinow, who's embarrassed about what happened with libGLU
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hamish Moffatt 2005-07-20, 5:58 pm |
| On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:
> On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
>
> Christ, not another one. Is there any sort of automated way that we can
> check for these sorts of libraries before messing things up again? I won't
Well, before I go and do the same, can anyone help me by checking
tqsllib?
Ubuntu has transitioned it in their 'universe' to tqsllib1c2.
However none of the exported headers contain the magic :: sign of C++,
so I suspect it's unnecessary. (A recompile to link against
libstdc++6 should be sufficient, without a name change).
thanks
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| GOMBAS Gabor 2005-07-20, 5:58 pm |
| On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:
> Christ, not another one. Is there any sort of automated way that we can
> check for these sorts of libraries before messing things up again?
Theoretically libraries should export only the symbols of their public
API, and such a check could be done by looking for C++-mangled names in
the list of exported symbols.
Practically libraries tend to be rather lousy and also export a lot of
internal symbols so you have to manually check if those symbols are
meant to be public or not (and if not then are there any applications
that use them regardless).
For example, both libaspell15 and libglu1-xorg export a lot of C++
symbols that are not meant to be part of the public API...
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Hendrik Sattler 2005-07-20, 5:58 pm |
| Hamish Moffatt wrote:
> Ubuntu has transitioned it in their 'universe' to tqsllib1c2.
> However none of the exported headers contain the magic :: sign of C++,
> so I suspect it's unnecessary. (A recompile to link against
> libstdc++6 should be sufficient, without a name change).
Is a non-present "::" really a sign that names don't get mangled? AFAIK an
extern C declaration is needed.
HS
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian Nelson 2005-07-20, 5:58 pm |
| On Wed, Jul 20, 2005 at 09:52:13AM +0200, Goswin von Brederlow wrote:
> Brian Nelson <pyro@debian.org> writes:
>
> Why? This is exactly what a versioned conflict is for. The packages
> have to be upgraded as pair and apt/dpkg will hapily do that.
Policy does not recommend it:
A Conflicts entry should almost never have an "earlier than" version
clause. This would prevent dpkg from upgrading or installing the
package which declared such a conflict until the upgrade or removal of
the conflicted-with package had been completed.
> Having libaspell15c2 conflict libaspell15 makes it no easier than
> having libaspell15 conflict the old aspell-bin.
Well, libaspell15c2 conflicts/replaces with libaspell15, which dpkg may
handle differently than a pure conflicts.
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-07-20, 8:48 pm |
| On Wed, Jul 20, 2005 at 11:42:40PM +1000, Hamish Moffatt wrote:
> On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> Well, before I go and do the same, can anyone help me by checking
> tqsllib?
> Ubuntu has transitioned it in their 'universe' to tqsllib1c2.
> However none of the exported headers contain the magic :: sign of C++,
> so I suspect it's unnecessary. (A recompile to link against
> libstdc++6 should be sufficient, without a name change).
Yeah, this is another lib with a C++ implementation that only exports a C
ABI in its headers. (other telltale signs to look for besides '::', btw are
'use', 'class', 'operator'; but that may obviously give false positives.)
The C++ bits within the library are a whole lot of template implementations,
and a few internal classes that are only exposed in the headers via C
wrappers. If you're sure that nothing out there is using tsqllib internals
inappropriately, then there's no need for a package name change.
As others have pointed out, ideally in this case you would have a linker
script that prevents these internal symbols from being exposed at all in the
library symbol table.
--
Steve Langasek
postmodern programmer
| |
| Steve Langasek 2005-07-21, 7:49 am |
| On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
> Steve Langasek <vorlon@debian.org> writes:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> Reintroducing the libaspell15 could cause problems with /usr/bin/aspell,
> since it actually goes outside the C API of libaspell and uses C++
> linkage to some symbols. I "fixed" this bug (#307481) by making
> aspell-bin (or now just aspell) depend on the Source-Version of
> libaspell.
> However, that fix is not in the stable package of aspell. In stable,
> aspell-bin just depends on libaspell15 (>= 0.60), so a partial upgrade
> of just libaspell15 would break aspell-bin. I suppose I could make the
> new libaspell15 conflict with the old aspell-bin, but that's rather
> clumsy and could make upgrades even more awkward.
> I'm not sure what the best thing to do would be. I'm sort of inclined
> to just stick with the transitioned libaspell15c2...
Well, using libaspell15c2 will definitely cause some complexity on the
upgrade path from sarge to etch. I don't know how much having libaspell15
conflict with aspell-bin (<< $version) would do so. I suspect that it
would be substantially less since there are only four packages in sarge
which depend directly on aspell-bin or aspell, vs. 61 packages which depend
on libaspell15 -- at a minimum, the worst-case scenario when conflicting
with aspell-bin (<< $version) looks substantially better.
--
Steve Langasek
postmodern programmer
| |
| Steve Langasek 2005-07-21, 7:49 am |
| On Wed, Jul 20, 2005 at 09:52:13AM +0200, Goswin von Brederlow wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> Why? This is exactly what a versioned conflict is for.
That doesn't mean the packaging tools handle the case gracefully (by user
standards). Most of the upgrade problems people saw with woody->sarge had
to do precisely with these << conflicts that policy counter-recommends.
> The packages have to be upgraded as pair and apt/dpkg will hapily do
> that.
Or, apt will happily *remove* the conflicted-with package instead...
But anyway, see my previous message for why the conflict with aspell may be
less problematic on upgrades.
--
Steve Langasek
postmodern programmer
| |
| Steve Langasek 2005-07-21, 7:49 am |
| On Wed, Jul 20, 2005 at 09:28:22AM -0400, David Nusinow wrote:
> On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> Christ, not another one. Is there any sort of automated way that we can
> check for these sorts of libraries before messing things up again? I won't
> be doing it again for libGLU obviously, but some sort of script or
> large-scale automated check of the archive would potentially go a long way.
The best heuristic I can come up with so far is
dpkg -x $package tmpdir && \
grep -rE '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>' tmpdir/usr/include
That may turn up false positives due to the use of common English words, but
I can't think of a way it could turn up false negatives. At any rate,
libGLU is still a false positive by this standard, so it really takes
someone who understands the ABI stuff to examine the occurrences of these
terms in each header.
It also doesn't address the possible problem of packages accessing private
symbols from the library. If we could get library authors/maintainers to
start using gcc -Wl,--version-script,<file with list of symbols to export>,
then we'd be able to use the much more reliable method of feeding the list
of symbols defined in the lib to c++filt and looking for '::' in the output.
--
Steve Langasek
postmodern programmer
| |
| Petri Latvala 2005-07-21, 7:49 am |
| On Thu, Jul 21, 2005 at 01:15:55AM -0700, Steve Langasek wrote:
> The best heuristic I can come up with so far is
>
> dpkg -x $package tmpdir && \
> grep -rE '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>' tmpdir/usr/include
>
> That may turn up false positives due to the use of common English words, but
> I can't think of a way it could turn up false negatives. At any rate,
> libGLU is still a false positive by this standard, so it really takes
> someone who understands the ABI stuff to examine the occurrences of these
> terms in each header.
What is this 'use'? C++ doesn't have that as a keyword. Do you mean
'using'?
--
Petri Latvala
| |
| Steve Langasek 2005-07-21, 7:49 am |
| On Thu, Jul 21, 2005 at 11:30:58AM +0300, Petri Latvala wrote:
> On Thu, Jul 21, 2005 at 01:15:55AM -0700, Steve Langasek wrote:
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> What is this 'use'? C++ doesn't have that as a keyword. Do you mean
> 'using'?
Sorry, yes.
--
Steve Langasek
postmodern programmer
| |
| Brian Nelson 2005-07-21, 6:03 pm |
| Steve Langasek <vorlon@debian.org> writes:
> On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
> /usr/bin/aspell,
>
> the
>
>
> Well, using libaspell15c2 will definitely cause some complexity on the
> upgrade path from sarge to etch. I don't know how much having
> libaspell15
> conflict with aspell-bin (<< $version) would do so. I suspect that it
> would be substantially less since there are only four packages in sarge
> which depend directly on aspell-bin or aspell, vs. 61 packages which
> depend
> on libaspell15 -- at a minimum, the worst-case scenario when conflicting
> with aspell-bin (<< $version) looks substantially better.
OK, very well then, I'll undo the GCC 4 transition for libaspell15.
BTW, does anyone familiar with gettext want to send me a patch for RC
bug #316666? Upstream said he plans to make a new release with an
upgrade to gettext 0.14.5 sometime this week, but I haven't heard
anything else from him.
--
Society is never going to make any progress until we all learn to
pretend to like each other.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-21, 6:03 pm |
| Brian Nelson <pyro@debian.org> writes:
> Steve Langasek <vorlon@debian.org> writes:
>
>
> OK, very well then, I'll undo the GCC 4 transition for libaspell15.
>
> BTW, does anyone familiar with gettext want to send me a patch for RC
> bug #316666? Upstream said he plans to make a new release with an
> upgrade to gettext 0.14.5 sometime this week, but I haven't heard
> anything else from him.
I just run gettextize, aclocal, automake (version 1.7 is needed irrc),
autoconf and recompiled. That seemed to have fixed it for me.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Martin v. Löwis 2005-07-22, 2:57 am |
| Brian Nelson wrote:
> OK, very well then, I'll undo the GCC 4 transition for libaspell15.
Isn't there still a binary-compatibility issue here? I thought that
in an application, there must only be one version of libstdc++,
directly or indirectly. Otherwise, during runtime, symbols may resolve
from the "wrong" libstdc++, causing crashes.
So if libaspell is linked with libstdc++.so.6, and some application
links to both libaspell (through the C API), and libstdc++.so.5 (because
it is a C++ application), this application may crash, as it might pick
up symbol definitions from libstdc++.so.6 - or libaspell might crash
as it picks up some symbols from libstdc++.so.5, and some from
libstdc++.so.6.
Regards,
Martin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steve Langasek 2005-07-22, 2:57 am |
| On Fri, Jul 22, 2005 at 09:13:00AM +0200, "Martin v. Löwis" wrote:
> Brian Nelson wrote:
[vbcol=seagreen]
> Isn't there still a binary-compatibility issue here? I thought that
> in an application, there must only be one version of libstdc++,
> directly or indirectly. Otherwise, during runtime, symbols may resolve
> from the "wrong" libstdc++, causing crashes.
> So if libaspell is linked with libstdc++.so.6, and some application
> links to both libaspell (through the C API), and libstdc++.so.5 (because
> it is a C++ application), this application may crash, as it might pick
> up symbol definitions from libstdc++.so.6 - or libaspell might crash
> as it picks up some symbols from libstdc++.so.5, and some from
> libstdc++.so.6.
All of the symbols provided by both libstdc++.so.6 and libstdc++.so.5 are
versioned; I don't think there's any real risk here of crashes due to
picking the wrong symbols at runtime.
--
Steve Langasek
postmodern programmer
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian Nelson 2005-07-22, 2:57 am |
| "Martin v. L=F6wis" <martin@v.loewis.de> writes:
> Brian Nelson wrote:
>
> Isn't there still a binary-compatibility issue here? I thought that
> in an application, there must only be one version of libstdc++,
> directly or indirectly. Otherwise, during runtime, symbols may resolve
> from the "wrong" libstdc++, causing crashes.
>
> So if libaspell is linked with libstdc++.so.6, and some application
> links to both libaspell (through the C API), and libstdc++.so.5 (because
> it is a C++ application), this application may crash, as it might pick
> up symbol definitions from libstdc++.so.6 - or libaspell might crash
> as it picks up some symbols from libstdc++.so.5, and some from
> libstdc++.so.6.
AFAIK, libstdc++ uses versioned symbols to prevent these problems...
--=20
Society is never going to make any progress until we all learn to
pretend to like each other.
| |
| Denis Barbier 2005-07-22, 5:56 pm |
| [Steve Langasek]
> The best heuristic I can come up with so far is
>
> dpkg -x $package tmpdir && \
> grep -rE '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>' tmpdir/usr/include
>
> That may turn up false positives due to the use of common English words, but
> I can't think of a way it could turn up false negatives.
Here is one ;)
$ export LC_ALL=et_EE.UTF-8
$ echo '#include <vorlon>' | grep -E '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>'
$
When bracket expressions are used within regular expressions of commands
which are influenced by LC_COLLATE (like grep, sed, ...), LC_ALL must be
set to C before running this command.
An alternative way is to replace [a-zA-Z_/] by [[:alpha:]_/] though I am
not 100% sure whether it is mandated that any locale has all ASCII letters
in its alpha character class.
Denis
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-07-22, 5:56 pm |
| Denis Barbier <barbier@linuxfr.org> writes:
> [Steve Langasek]
>
> Here is one ;)
> $ export LC_ALL=et_EE.UTF-8
> $ echo '#include <vorlon>' | grep -E '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>'
> $
>
> When bracket expressions are used within regular expressions of commands
> which are influenced by LC_COLLATE (like grep, sed, ...), LC_ALL must be
> set to C before running this command.
> An alternative way is to replace [a-zA-Z_/] by [[:alpha:]_/] though I am
> not 100% sure whether it is mandated that any locale has all ASCII letters
> in its alpha character class.
>
> Denis
I think he ment something like:
/*
* This is the C interface to the c++ template class the library is
* using internaly.
*/
void* get_obj(obj* class_obj);
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marcelo E. Magallon 2005-07-26, 8:00 am |
| On Wed, Jul 20, 2005 at 02:51:14PM -0700, Steve Langasek wrote:
> Yeah, this is another lib with a C++ implementation that only exports
> a C ABI in its headers. (other telltale signs to look for besides
> '::', btw are 'use', 'class', 'operator'; but that may obviously give
> false positives.) The C++ bits within the library are a whole lot of
> template implementations, and a few internal classes that are only
> exposed in the headers via C wrappers. If you're sure that nothing
> out there is using tsqllib internals inappropriately, then there's no
> need for a package name change.
Actually the proper way is to check the public headers and look if the
interface is guarded with extern "C" { ... }. There _must_ be a
check like:
#ifdef __cplusplus
extern "C" {
#endif
/* ... */
#ifdef __cplusplus
}
#endif
Just take the public header and pass it thru the preprocessor:
$ g++ -E /usr/include/GL/gl.h | grep -v ^#
look for the bits outside the extern "C" linkage:
typedef int ptrdiff_t;
typedef unsigned int size_t;
that's harmless. Let's say you do find something like:
extern void glEnableTraceMESA( GLbitfield mask );
_outside_ the extern "C" block... that is _not_ harmless.
A small parser that looks for extern "C", the "{" right after it and
the matching "}" should make things much easier.
--
Marcelo
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marcelo E. Magallon 2005-07-26, 8:00 am |
| On Mon, Jul 25, 2005 at 08:39:26PM -0600, Marcelo E. Magallon wrote:
> A small parser that looks for extern "C", the "{" right after it and
> the matching "}" should make things much easier.
The attached script should work in most cases.
--
Marcelo
|
|
|
|
|