Re: aspell upgrade woes
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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 $n = 0;
while ()
{
last if /extern\s+C/;
print;
}
do { $n++ if /{/ } while ($n == 0 ($_ = ));
while ($n 0 ($_ = ))
{
$n++ if /{/;
$n-- if /}/;
}
print while ;
Re: aspell upgrade woes
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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++, 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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. 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... -- Society is never going to make any progress until we all learn to pretend to like each other.
Re: aspell upgrade woes
[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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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. 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 signature.asc Description: Digital signature
Re: aspell upgrade woes
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 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. 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 signature.asc Description: Digital signature
Re: aspell upgrade woes
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. [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. 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 signature.asc Description: Digital signature
Re: aspell upgrade woes
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 signature.asc Description: Digital signature
Re: aspell upgrade woes
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_/]+' 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'? Sorry, yes. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: aspell upgrade woes
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 (#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. 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 #31? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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. 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 #31? 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 signature.asc Description: Digital signature
Re: aspell upgrade woes
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 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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. 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 already installed libaspell15c2, and are in the middle of the cut-over? [snip] -- Ron Johnson [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: aspell upgrade woes
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 again. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: aspell upgrade woes
[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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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 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 [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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. 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: aspell upgrade woes
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-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. We've never treated this as grounds for a package name change in the absence of an upstream soname change before; I don't see any reason why we would want to special-case it here. The better answer here is don't let libraries you depend on use unversioned symbols, but we're a pretty long way away from that yet. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: aspell upgrade woes
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 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 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 signature.asc Description: Digital signature
aspell upgrade woes
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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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 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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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]
Re: aspell upgrade woes
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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aspell upgrade woes
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? 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 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? 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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
