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
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
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
[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
"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 indirec
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++,
>
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
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 use
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
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_/]+>'
> > tm
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 o
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
> >
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-
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 i
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 transiti
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
> >non
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 a
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: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 chec
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 thou
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 expo
[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
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 wrong
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
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
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
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 yeste
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 AB
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-sev
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]
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
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 l
32 matches
Mail list logo