Re: Dependencies on shared libs, news and difference between archs
On Fri, 2007-08-31 at 00:15:10 -0700, Steve Langasek wrote: On Fri, Aug 31, 2007 at 06:09:42AM +0300, Guillem Jover wrote: For libraries with versioned symbols, just checking for the needed version nodes should be enough, and I'd say that adding symbols to a previously existing version node or breaking their ABI is broken, and something that we should not tolerate. Huh? Adding new symbols without adding new version nodes doesn't break anything of substance, so why would you say this is broken? I'd say it's conceptually broken, although it was probably missleading to present those two cases as if they had the same severity. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
On Mon, Sep 10, 2007 at 05:00:04AM +0300, Guillem Jover wrote: On Fri, 2007-08-31 at 00:15:10 -0700, Steve Langasek wrote: On Fri, Aug 31, 2007 at 06:09:42AM +0300, Guillem Jover wrote: For libraries with versioned symbols, just checking for the needed version nodes should be enough, and I'd say that adding symbols to a previously existing version node or breaking their ABI is broken, and something that we should not tolerate. Huh? Adding new symbols without adding new version nodes doesn't break anything of substance, so why would you say this is broken? I'd say it's conceptually broken, although it was probably missleading to present those two cases as if they had the same severity. I disagree that it's conceptually broken either. It happens to not be the use of symbol versioning advocated by certain people, but unless you're maintaining a library (= glibc) that will have multiple versions of a symbol available in the same .so, that method increases the upstream maintenance overhead for symbol versions with no benefit to the user. -- 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]
Re: Dependencies on shared libs, news and difference between archs
Hi, On Fri, 31 Aug 2007, Guillem Jover wrote: On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote: I think my work is mostly ready for unstable as it is. The last step is to convince Guillem Jover, the main dpkg maintainer, to merge that in the master branch. He believes that supporting odd cases encourages bad practice on library management. I don't think so. On the contrary I'd like to promote sane library management and I made some efforts in the included documentation to promote that. First, thanks for your work on this! For libraries with versioned symbols, just checking for the needed version nodes should be enough, and I'd say that adding symbols to a previously existing version node or breaking their ABI is broken, and something that we should not tolerate. We could try to change dpkg-gensymbols to be smarter about this. If it detects that the library is using versioned symbols (i.e. version is different from Base), then we tolerate less. But it's not as easy as it seems. For example glibc uses GLIBC_PRIVATE versioned symbols which can change as they are internal between various glibc related objects but they are not meant to be used by others. (this did happen betwen etch's glibc and the current one) On the other hand, not merging the code also means continuing to tolerate even more problems, so my work is not a regression at all. But for libraries w/o versioned symbols your solution is the most reasonable, for now libs with versioned symbols could use it as well and we can add a different mode for version-node-only support afterwards. Indeed, but I'm not sure that such a mode is really needed (except maybe for C++ versioned libraries if that exists where it might avoid having to handle arch-specific symbol files for very little gain). I'd rather continue to have the full symbol information available and make our tools check more rigorously in those cases where we know that we should expect more. So let's start the merging process anyway, I'll try to review the branch in the next days, although Frank has been tracking this, I'm not sure if he did a final review. Frank didn't review the changes made after the introduction of the manual pages (after 2007-07-16). Any chance this can be included in your monday upload? Or at least, that we merge it directly after and make an experimental upload so that we can start working a bit further in the integration with debhelper for example. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
On Fri, Aug 31, 2007 at 06:09:42AM +0300, Guillem Jover wrote: On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote: I think my work is mostly ready for unstable as it is. The last step is to convince Guillem Jover, the main dpkg maintainer, to merge that in the master branch. He believes that supporting odd cases encourages bad practice on library management. I don't think so. On the contrary I'd like to promote sane library management and I made some efforts in the included documentation to promote that. First, thanks for your work on this! For libraries with versioned symbols, just checking for the needed version nodes should be enough, and I'd say that adding symbols to a previously existing version node or breaking their ABI is broken, and something that we should not tolerate. Huh? Adding new symbols without adding new version nodes doesn't break anything of substance, so why would you say this is broken? -- 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]
Re: Dependencies on shared libs, news and difference between archs
Hi Raphael, On Wed, 2007-08-22 at 15:19:02 +0200, Raphael Hertzog wrote: I think my work is mostly ready for unstable as it is. The last step is to convince Guillem Jover, the main dpkg maintainer, to merge that in the master branch. He believes that supporting odd cases encourages bad practice on library management. I don't think so. On the contrary I'd like to promote sane library management and I made some efforts in the included documentation to promote that. First, thanks for your work on this! For libraries with versioned symbols, just checking for the needed version nodes should be enough, and I'd say that adding symbols to a previously existing version node or breaking their ABI is broken, and something that we should not tolerate. But for libraries w/o versioned symbols your solution is the most reasonable, for now libs with versioned symbols could use it as well and we can add a different mode for version-node-only support afterwards. So let's start the merging process anyway, I'll try to review the branch in the next days, although Frank has been tracking this, I'm not sure if he did a final review. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
On Wed, 22 Aug 2007 15:19:02 +0200 Raphael Hertzog [EMAIL PROTECTED] wrote: Everything is available in the git branch: http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=dpkg-shlibdeps-buxy I think my work is mostly ready for unstable as it is. The last step is to convince Guillem Jover, the main dpkg maintainer, to merge that in the master branch. He believes that supporting odd cases encourages bad practice on library management. I don't think so. On the contrary I'd like to promote sane library management and I made some efforts in the included documentation to promote that. Feel free to check by yourself in the current version of dpkg-gensymbols's manpage: http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=man/dpkg-gensymbols.1;h=8bd39979599ba9580fa164cdddf73039a0e6c011;hb=40ed7b0685cfe9160dfd3a34b7babe3e604c8d7c Your comments are welcome of course. Raphael - I'm in the middle of a rewrite of dpkg-cross, including the diversion of dpkg-shlibdeps: http://alioth.debian.org/plugins/scmcvs/cvsweb.php/dpkg-cross/?cvsroot=dpkg-cross The main objective is to close some really, really old bugs and make it easier to use dpkg-cross functions in other scripts, like apt-cross by providing libdebian-dpkgcross-perl (hence NEW). apt-cross will also provide libaptcross-perl (so that will go via NEW too) to better meet the needs of emdebian-tools. http://lists.debian.org/debian-embedded/2007/08/msg00021.html http://lists.debian.org/debian-embedded/2007/08/msg00036.html http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/42-dpkg-cross-1.99+2.0.0pre1-in-NEW.html dpkg-cross v1.99+2.0.0pre1 is currently in the NEW queue, destined for experimental. I've planned a couple more pre-releases before it migrates to unstable. I have a branch of apt-cross that uses the rewritten dpkg-cross and I have amendments to emdebian-tools that will complete the trilogy. So far, pre1 is largely complete for dpkg-cross and the dpkg-buildpackage diversion, barring an unknown number of possible corner cases. It would be good if we could work together to close #283626 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283626 (which is 2 years and 265 days old!) where the patch against dpkg-cross 1.20 (itself based on dpkg-1.10.25) is now out of date from both angles. I'd appreciate any input you can provide because dpkg-shlibdeps isn't particularly familiar to me and I purposely left this part of dpkg-cross until this stage of the rewrite. I'd like to be able to not need dpkg-shlibdeps in dpkg-cross but if the version in dpkg is not ready to be cross-compiler aware, a merge with the latest dpkg code is well overdue. PS: For those who didn't follow the whole story, I'm speaking here of that project: http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps Emdebian has a lot to gain from a more intelligent dpkg-shlibdeps to help prune the dependency tree ever further. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpUSDizYp1yN.pgp Description: PGP signature
Re: Dependencies on shared libs, news and difference between archs
On Wed, 22 Aug 2007, Neil Williams wrote: I'd appreciate any input you can provide because dpkg-shlibdeps isn't particularly familiar to me and I purposely left this part of dpkg-cross until this stage of the rewrite. I'd like to be able to not need dpkg-shlibdeps in dpkg-cross but if the version in dpkg is not ready to be cross-compiler aware, a merge with the latest dpkg code is well overdue. Well, this is a topic for once my dpkg-shlibdeps implementation has been merged. But feel free to explain your needs in [EMAIL PROTECTED] You've given lots of links and info but I don't really know in what situation you are calling dpkg-shlibdeps and what kind of change do you need. I'm however fully aware that dpkg-shlibdeps is not really cross-compiling friendly. It's also difficult to be friendly since all the information that it uses comes from /var/lib/dpkg/info/ which corresponds to the the host information (and not the info of the target) and AFAIK there's not standard location that we can use to lookup the information corresponding to the target. In summary, please sum up your needs in a new mail that you send to [EMAIL PROTECTED] and maybe open a bug report on the topic. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
On Wed, Aug 22, 2007 at 03:19:02PM +0200, Raphael Hertzog wrote: Hi, 2/ Second example, libconfig0 has a supplementary symbols [...] _PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes from. Is this a internal symbols that I missed? http://www.cygwin.com/ml/binutils/2004-05/msg00577.html seems to suggest that only sparc and alpha want the PLT as a symbol. On powerpc it has _SDA_BASE_ and _SDA2_BASE_. Same question as above. The Small Data Areas (SDA) seems to be ppc specific, and is mentioned in the elfspec_ppc.pdf. It's about data that can be access with 16 bit offset. On amd64 it has lost the _DYNAMIC symbol. Same question as above. It seems this can be hidden: http://sourceware.org/ml/binutils/2005-08/msg00190.html amd64 built this package only in 2006, the rest did in 2003. I'm guessing building this again will remove it on other arches. Quick googling led me to believe that I can/should exclude all those. If someone can confirm, it would be great. I agree. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
Raphael Hertzog wrote: [snip] 2/ Second example, libconfig0 has a supplementary symbols _PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes from. Is this a internal symbols that I missed? On powerpc it has _SDA_BASE_ and _SDA2_BASE_. Same question as above. On amd64 it has lost the _DYNAMIC symbol. Same question as above. The symbols for PLT and dynamic section are magic for the dynamic loader, they aren't relevant WRT shared library dependencies. I guess the same applies to the powerpc SDA symbols. Quick googling led me to believe that I can/should exclude all those. If someone can confirm, it would be great. 3/ Third example, libgci0/0.9.5.dfsg-2 on mipsel has a 0x62 global symbol: 009b6870 gD *ABS* 009b6170 0x62 It also has a 0x63 symbol but this one is marked local so is already discarded. 009b4cb0 lD *ABS* 009b6580 0x63 I have no idea where they come from and what they're used for. Can someone from debian-mips enlighten me? Looks like a corrupted symbol table. 4/ Fourth example, libgarlic2006 on alpha has many supplementary symbols ending in ___elabs. No idea what the root difference is. 5/ Fifth example, it looks like 64 bits ports tend to have differences in common like on libneon2.6 where various functions suffixed by 64 disappear on those arches (ne_get_range64, ne_set_request_body_fd64, ne_set_request_body_provider64). 64bit ports tend to handle 64bit offsets in their interface functions, so they don't need special versions for e.g. LFS. If you want to investigate a bit more on differences, you can grab that file: http://users.alioth.debian.org/~hertzog/comparison.tar.bz2 (139 Mb) the result-compare contain the information about differences on all packages. You can then lookup the difference manually by diffing files in result/sid/*.symbols.* About C++ libraries --- Can anyone explain me why there's randomness in symbol mangling? If I compare the symbols file of gnunet-qt for example I get differences like this between i386 and alpha: @@ -67,10 +67,10 @@ [EMAIL PROTECTED] 0.7.1-1 [EMAIL PROTECTED] 0.7.1-1 [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 - [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 + [EMAIL PROTECTED] 0.7.1-1 libgnunetqtmodule_about.so.1 gnunet-qt #MINVER# [EMAIL PROTECTED] 0.7.1-1 [EMAIL PROTECTED] 0.7.1-1 But if you check what it refers too, they refer to the same symbol: $ c++filt _ZThn8_N11GTextEditorD0Ev non-virtual thunk to GTextEditor::~GTextEditor() $ c++filt _ZThn16_N11GTextEditorD0Ev non-virtual thunk to GTextEditor::~GTextEditor() And if I convert the symbols files with c++filt then both files are identical. Different object/vtable layout, see http://www.codesourcery.com/cxx-abi/abi.html#mangling Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies on shared libs, news and difference between archs
On Wed, Aug 22, 2007 at 03:19:02PM +0200, Raphael Hertzog wrote: 5/ Fifth example, it looks like 64 bits ports tend to have differences in common like on libneon2.6 where various functions suffixed by 64 disappear on those arches (ne_get_range64, ne_set_request_body_fd64, ne_set_request_body_provider64). This should hopefully be fairly common. Things with large file support will have separate versions of APIs that need to take into account _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS will have separate versions of affected symbols for platforms where they make a difference. Platforms where file size related types are all naturally 64 bit don't need the extra versions of the symbols. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Dependencies on shared libs, news and difference between archs
On Wed, 2007-08-22 at 20:38 +0100, Thiemo Seufer wrote:
snip
Can anyone explain me why there's randomness in symbol mangling? If I
compare
the symbols file of gnunet-qt for example I get differences like this
between
i386 and alpha:
@@ -67,10 +67,10 @@
[EMAIL PROTECTED] 0.7.1-1
[EMAIL PROTECTED] 0.7.1-1
[EMAIL PROTECTED] 0.7.1-1
- [EMAIL PROTECTED] 0.7.1-1
- [EMAIL PROTECTED] 0.7.1-1
- [EMAIL PROTECTED] 0.7.1-1
- [EMAIL PROTECTED] 0.7.1-1
+ [EMAIL PROTECTED] 0.7.1-1
+ [EMAIL PROTECTED] 0.7.1-1
+ [EMAIL PROTECTED] 0.7.1-1
+ [EMAIL PROTECTED] 0.7.1-1
libgnunetqtmodule_about.so.1 gnunet-qt #MINVER#
[EMAIL PROTECTED] 0.7.1-1
[EMAIL PROTECTED] 0.7.1-1
But if you check what it refers too, they refer to the same symbol:
$ c++filt _ZThn8_N11GTextEditorD0Ev
non-virtual thunk to GTextEditor::~GTextEditor()
$ c++filt _ZThn16_N11GTextEditorD0Ev
non-virtual thunk to GTextEditor::~GTextEditor()
And if I convert the symbols files with c++filt then both files are
identical.
Different object/vtable layout, see
http://www.codesourcery.com/cxx-abi/abi.html#mangling
Another difference: (u)int64_t are aliases for (unsigned) long long on
32-bit systems and are mangled as 'x' ('y'). On 64-bit systems they are
aliases for (unsigned) long and are mangled as 'l' ('m').
Ben.
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
signature.asc
Description: This is a digitally signed message part
Re: Dependencies on shared libs, news and difference between archs
Hi, On Wed, 2007-08-22 at 15:08:16 +0100, Neil Williams wrote: Raphael - I'm in the middle of a rewrite of dpkg-cross, including the diversion of dpkg-shlibdeps: So far, pre1 is largely complete for dpkg-cross and the dpkg-buildpackage diversion, barring an unknown number of possible corner cases. I don't think those diversions are a good solution... It would be good if we could work together to close #283626 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283626 (which is 2 years and 265 days old!) I already offered my help on debian-embedded to try to merge dpkg-cross into dpkg-dev, which would be the proper place for that functionallity, instead of forking it. Anyway, as Raphael said, the correct venue for this discussion is debian-dpkg, feel free to start it there. My offer still holds and I'm sure others will also be glad to help. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
