Re: Bug#430266: ldbl128 transition for alpha, powerpc, sparc, s390
On Sat, Jun 23, 2007 at 03:48:06PM +0200, Matthias Klose wrote: Discussed in http://lists.debian.org/debian-devel/2007/05/msg01173.html There's not a lot of discussion there -- just an announcement really. 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. The referenced message, above, is over three weeks old. Is that when the change went in? Does that mean any package on the list built since then is buggy? To allow partial upgrades of packages, we will need to rename all packages holding libraries with the long double data type in their API. So what upgrades are we worried about? If packages built in the last three weeks are buggy, they may already be in testing. So we're not to worry about upgrades from testing versions? If we're only worried about upgrades from the version in stable, then we don't need to rename a package that has never been in stable, correct? 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). How is it that libc and libstdc++ support both representations? How would another library support both? Thanks, -Steve signature.asc Description: Digital signature
re: ldbl128 transition for alpha, powerpc, sparc, s390
Hi, Looking at my packages that doko flagged for this transition, I see at least one place where on some platforms (though not for any Debian arch) a long double may be passed to an api function as a vararg. If there are other such packages they may not have been caught by his scan for 'long *double'. Finding them automatically could be an interesting exercise for some lucky reader ... There probably aren't many that fit that description, but there may be a couple so I figured its worth giving people a head-up about. Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldbl128 transition for alpha, powerpc, sparc, s390
In gmane.linux.debian.devel.general Matthias Klose [EMAIL PROTECTED] wrote: 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. Attached you can find a list of packages with header files in /usr/include matching 'long *double'. If a library package is built from the same source as well, it has to be renamed, however the list may have false positives. [...] gnulib [...] Looks like a false positive. The gnulib source package is arch-all, it does not contain compiled source. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldbl128 transition for alpha, powerpc, sparc, s390
Matthias Klose wrote: I plan to submit bug reports with severity `serious' for all source packages matching the above description (although if somebody wants to handle this transition, please go ahead). cfortran Probably a false positive, as it is an arch:all package (just a header file). Cheers, Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldbl128 transition for alpha, powerpc, sparc, s390
On Thu, May 31, 2007 at 11:36:55PM +0200, Matthias Klose wrote: php4-dev This package is EOL and will not be fixed for this transition (assuming it applies). php5-dev This is a false positive, the only use of 'long double' in the php5 header files is in a macro definition. Please exclude these packages from your mass filing. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ldbl128 transition for alpha, powerpc, sparc, s390
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. Attached you can find a list of packages with header files in /usr/include matching 'long *double'. If a library package is built from the same source as well, it has to be renamed, however the list may have false positives. Still unsure about how to handle extension modules in scripting languages; looking at python it may be sufficient to add conflicts with all extension modules exposing the long double datatype in their APIs. I plan to submit bug reports with severity `serious' for all source packages matching the above description (although if somebody wants to handle this transition, please go ahead). Matthias atlas3-headers cfortran cmix crystalspace-dev dietlibc-dev ecl elks-libc erlang-dev etl-dev felix fftw3-dev fftw-docs gclcvs gettext ghdl gnulib harbour kmymoney2 lam4-dev lcrash-dev libace-dev libalps-light1-dev libbind-dev libbinio-dev libblitz0-dev libcln-dev libclucene-dev libcppunit-dev libdbi-perl libfcgi-dev libglib1.2-dev libgmp3-dev libgoffice-1-dev libgraphicsmagick1-dev libgraphviz3-dev libgsl0-dev libhdf5-lam-dev libhdf5-mpich-dev libhdf5-serial-dev libhk-classes-dev libicu36-dev libimager-perl libinsighttoolkit-dev libitpp-dev liblo0-dev libloki-dev liblpsolve55-dev liblua5.1-0-dev libmagick9-dev libmpfr-dev libmpich1.0-dev libmpich-mpd1.0-dev libmpich-shmem1.0-dev libnewlib-headers libnewmat10-dev libniftiio0-dev libomniorb4-dev libopenexr-dev liborbit2cpp-dev liborbit2-dev liborbit-dev liborsa0-dev libosp-dev libostyle-dev libparrot-dev libpetsc2.3.2-dev libpoco-dev libpqxx-dev libpt-dev libqd-dev libqhull-dev libqt4-dev librudiments-dev libsmi2-dev libsscm-dev libstk0-dev libstlport4.6-dev libstlport5.0-dev libstlport5.1-dev libsundials-serial-dev libtao-dev libterralib1-dev libuclibc-dev libvigraimpex-dev libwine-dev libwv2-dev libwvstreams-dev libwww-dev libwww-ssl-dev llvm llvm-cfe lsb-build-base2 lsb-build-base3 mercury meschach-dev nickle openmpi-dev pdl perl php4-dev php5-dev pike7.6-dev pnetc pnet-dev postfix-dev python2.4-dev python2.5-dev python-numpy python-scipy python-scipy-core sparsehash splint tcc tendra wireshark-dev wx2.4-headers wx2.6-headers xemacs21-bin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldbl128 transition for alpha, powerpc, sparc, s390
On Thu, 31 May 2007, Matthias Klose wrote: Attached you can find a list of packages with header files in /usr/include matching 'long *double'. [...] gettext I don't understand this, as grep double `dpkg -L gettext | grep include/` outputs nothing. Is this a false positive? [ Please keep Cc: debian-devel, as I'm not subscribed to -toolchain ]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ldbl128 transition for alpha, powerpc, sparc, s390
On Thu, May 31, 2007 at 11:36:55PM +0200, Matthias Klose wrote: 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. Attached you can find a list of packages with header files in /usr/include matching 'long *double'. If a library package is built from the same source as well, it has to be renamed, however the list may have false positives. Still unsure about how to handle extension modules in scripting languages; looking at python it may be sufficient to add conflicts with all extension modules exposing the long double datatype in their APIs. I plan to submit bug reports with severity `serious' for all source packages matching the above description (although if somebody wants to handle this transition, please go ahead). snip lsb-build-base2 lsb-build-base3 snip Given what the LSB is, I expect that at least these packages need to be updated to build using the old ABI. How can this be done? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
