Your message dated Thu, 1 Nov 2007 13:29:20 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#430249: ldbl128 transition for alpha, powerpc, sparc, s390
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: libdbi-perl
Severity: serious
User: [EMAIL PROTECTED]
Usertags: goal-ldbl128

Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html

With glibc-2.5 and gcc-4.1.2 (and gcc-4.2), the 'long double'
data type did change from a 64bit representation to a 128bit
representation on alpha, powerpc, sparc, s390. To allow
partial upgrades of packages, we will need to rename all
packages holding libraries with the long double data type in
their API.  Both libc and libstdc++ do not need to be renamed,
because they support both representations.  We rename the library
packages on all architectures to avoid name mismatches between
architectures (you can avoid the renaming by supporting both
datatype representations in the library as done in glibc and
libstdc++, but unless a library is prepared for that, it does not
        seem to be worth the effort).

It is suggested to rename a package libfoo1 to libfoo1ldbl;
please wait with the renaming if the package depends on
another library package which needs renaming.

This package has been indentified as one with header files in
/usr/include matching 'long *double'. Please close this bug report
if it is a false positive, or rename the package accordingly.


--- End Message ---
--- Begin Message ---
On Thu, Oct 25, 2007 at 03:01:11PM -0700, Steve Langasek wrote:
> On Tue, Oct 23, 2007 at 12:17:56PM +0300, Damyan Ivanov wrote:
> > [d-release CC-ed for oppinion]
> > [please CC at least debian-perl]
 
> > > > > On 2007-06-23 Matthias Klose wrote:
> > > > > > Package: libdbi-perl
 
> > > > > > This package has been indentified as one with header files in
> > > > > > /usr/include matching 'long *double'. Please close this bug report
> > > > > > if it is a false positive, or rename the package accordingly.

> It appears that libdbi-perl is included in the list for the ldbl transition
> because of the file /usr/lib/perl5/auto/DBI/dbipport.h.  I don't believe
> that anything in Debian builds against this file, but then I also don't know
> why it's in the package at all.  If other packages do build against this
> header, then there is at least potentially an ABI change that needs to be
> handled.  If this header is dead weight, then no changes need to be made to
> the libdbi-perl package for this bug report (not even "depending on a perl
> that is compiled with the new glibc/gcc").

The libdbd-*-perl packages do build against this file, through DBIXS.h.
The file provides a compatibility API for older versions of Perl so
that XS modules can use features introduced in newer versions. See
Devel::PPPort(3perl) for more information.

In this case, the relevant block is

 #ifndef NVTYPE
 #  if defined(USE_LONG_DOUBLE) && defined(HAS_LONG_DOUBLE)
 #    define NVTYPE long double
 #  else
 #    define NVTYPE double
 #  endif

which provides the NVTYPE definition when building with an old Perl that
doesn't know about it. Now, 'perl dbipport.h --api-info NVTYPE' says

 Supported at least starting from perl-5.6.0.
 Support by dbipport.h provided back to perl-5.003.

so this isn't used on Debian. Even if it were, our perl is compiled
without the 'uselongdouble' configuration parameter (see #430322), so the
'long double' alternative wouldn't be used anyway.

I'm closing the bug, please reopen if I have missed something. In that
case, #430264 should probably be reopened too.

Cheers,
-- 
Niko Tyni   [EMAIL PROTECTED]


--- End Message ---

Reply via email to