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.)
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
#!/usr/bin/perl
use strict;
use warnings;
my
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
On Fri, Jul 22, 2005 at 09:13:00AM +0200, Martin v. Löwis wrote:
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++,
Martin v. Löwis [EMAIL PROTECTED] writes:
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.
[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
Denis Barbier [EMAIL PROTECTED] writes:
[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
On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
Steve Langasek [EMAIL PROTECTED] writes:
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
On Wed, Jul 20, 2005 at 09:52:13AM +0200, Goswin von Brederlow wrote:
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
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:
Uh... no...
http://lists.debian.org/debian-devel-announce/2005/07/msg1.html
It's a C++ library and the ABI changed due to being compiled with GCC
4.0.
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
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:
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_/]+'
Steve Langasek [EMAIL PROTECTED] writes:
On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
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
Brian Nelson [EMAIL PROTECTED] writes:
Steve Langasek [EMAIL PROTECTED] writes:
On Tue, Jul 19, 2005 at 11:52:51PM -0700, Brian Nelson wrote:
Reintroducing the libaspell15 could cause problems with
/usr/bin/aspell,
since it actually goes outside the C API of libaspell and uses C++
linkage
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
Steve Langasek [EMAIL PROTECTED] writes:
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
Brian Nelson [EMAIL PROTECTED] writes:
Steve Langasek [EMAIL PROTECTED] writes:
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
On Wed, 2005-07-20 at 09:52 +0200, Goswin von Brederlow wrote:
Brian Nelson [EMAIL PROTECTED] writes:
Steve Langasek [EMAIL PROTECTED] writes:
[snip]
So I would say just drop libaspell15c and reupload anything that was
already wrongfully uploaded again.
What does that do to people who have
Ron Johnson [EMAIL PROTECTED] writes:
On Wed, 2005-07-20 at 09:52 +0200, Goswin von Brederlow wrote:
Brian Nelson [EMAIL PROTECTED] writes:
Steve Langasek [EMAIL PROTECTED] writes:
[snip]
So I would say just drop libaspell15c and reupload anything that was
already wrongfully uploaded
[EMAIL PROTECTED] 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
On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
Uh... no...
http://lists.debian.org/debian-devel-announce/2005/07/msg1.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
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:
[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
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
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 ::
On Wed, Jul 20, 2005 at 09:52:13AM +0200, Goswin von Brederlow wrote:
Brian Nelson [EMAIL PROTECTED] writes:
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
On Wed, Jul 20, 2005 at 08:15:41AM -0400, Nathanael Nerode wrote:
[EMAIL PROTECTED] 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
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:
On Tue, Jul 19, 2005 at 09:39:23PM -0700, Brian Nelson wrote:
[Actually, although it's written in C++, AFAIK it only exports a C
interface so the transition may
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
Brian Nelson [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] 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
Brian Nelson [EMAIL PROTECTED] writes:
[helpful stuff]
Thanks, I understand now.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Thomas Bushnell BSG [EMAIL PROTECTED] 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
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Brian Nelson [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] 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?
32 matches
Mail list logo
