On Sat, 17 Jun 2006 16:25:39 +0900 Junichi Uekawa wrote: > > > > When compiling a C++ library, d-shlibs resolves the > > > > build-dependency to the virtual package libstdc++6-dev which is > > > > provided only by the libstdc++ from gcc-3.4 source package > > > > (even if the package was actually compiled using the one from > > > > gcc-4.1). > > > > > > > > Compiling same C++ library on sarge the resolving fails, trying > > > > to build-depend on non-existing libstdc++5-dev. > > > > > > > > The attached patch fixes this for the cases of using default > > > > compiler. I suspect, however, that a proper fix also taking > > > > non-default compilers into account requires changes to the > > > > objdump analysis. > > > > > > Thanks. > > > > > > I think we have a choice. > > > > > > It's part of Build-Essential, so we should be able to ignore > > > libstdc++6-XXX-dev. For non-default compilers, we should also > > > ignore libstdc++XXX-dev and leave a note to add Build-Depends on g > > > ++-XX. > > > > Ah, yes: Build-essential. > > > > But how to resolve if it was the default compiler or not? > > > > If possible to resolve which are non-default compilers, then why not > > provide build-dependencies for them now we are at it? > > They are supposed to be compatible with each other, although the two > -dev packages contain different files, the actual shared library file > is one. I don't know why they decided to split the -dev package and > leave the .so file. > > Is there a compelling reason to use a non-default compiler version?
I am no expert in the field, but assume that if some library needs a specific version of a compiler, then it is quite likely that other software linking against that library will need same compiler. A concrete example is the linux kernel and out-of-tree modules, I believe. I guess the very existence of multiple concurrent versions of same compiler series demonstrate the need for sometimes explicitly using a different compiler, no? D-shlibs goes by the fundamental assumption that a shared library matches the package name, right? In the case of libstdc++ this assumption is wrong, and will in the simple case lead to pulling in useless dependencies, but I suspect in some cases will cause breakage due to not providing the actual _needed_ dependency: The case of depending on a library not provided by build-essential either. In my concrete case it makes sense to simply silence the dependency, but looking at your other workarounds, they seem to be mostly simplifications. What seems to be needed here is a complication instead: correcting a simpler package name to a more complex one - due to the package maintainers' odd choice of names, but that's the overall challenge we have to live with, when Debian Policy only recommends, not requires, strict library naming :-) - Jonas -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm
pgpJimKWW3bvy.pgp
Description: PGP signature
