Bug#454036: dpkg-dev: dpkg-shlibdeps misses symbols and thus outputs false warnings
Hi, a long mail with some IRC discussion of the problem. On Sun, 02 Dec 2007, Bernhard R. Link wrote: > dpkg-shlibdeps misses some symbols and thus prints warnings about not > using symbols from a library even when doing so. [...] > Thus those symbols are actually needed. (They are variables with the > object class of the widget, referencing the actual used methods as > function pointers, thus no other symbols from this library are used). > > | $ objdump -R debian/xbuffy/usr/bin/xbuffy > | debian/xbuffy/usr/bin/xbuffy: file format elf32-sparc > | > | DYNAMIC RELOCATION RECORDS > | OFFSET TYPE VALUE [...] > | 00028a40 R_SPARC_COPY boxWidgetClass [...] > | >From what I can tell, it seems not to be visible with -w -f -p -T: They are visible: > | $ objdump -w -f -p -T debian/xbuffy/usr/bin/xbuffy > | debian/xbuffy/usr/bin/xbuffy: file format elf32-sparc > | architecture: sparc:v8plus, flags 0x0112: > | EXEC_P, HAS_SYMS, D_PAGED > | start address 0x00011660 [...] > | DYNAMIC SYMBOL TABLE: [...] > | 00028a40 gDO .bss 0004 boxWidgetClass Except that the symbol is marked as contained in .bss section. Since I didn't know the precise role of that .bss section (documentation says it's for uninitialized data) I asked vorlon: buxy: 454036: definitely a dpkg-dev bug, data symbols should also be part of the list being checked [...] the bug log has has the relevant objdump output on the binary right The problem being it's a copy relocation? yes, seems so Q_: do you know of any case when there should be an exported symbol in .bss that /isn't/ a copy relocation? I have no idea. ok buxy: my guess is that it's reasonable, at least as a next pass, to treat all .bss symbols you find as unresolved symbols if we find exceptions, we can sort those out after : But after some more reseach it appeared that it's not really reasonable: vorlon: I don't think I can consider dynamic symbols marked contained in .bss as undefined... vorlon: because I see for example on objdump -T /bin/ls: 0805b864 g DO .bss 0004 GLIBC_2.0 optarg and on libc6: 0011a6bc gDO .bss 0004 GLIBC_2.0 optarg and undefined on both sides doesn't make sense buxy: ah, neat :) buxy: In libc6 it also has a relocation: R_X86_64_GLOB_DAT optarg Q_: yeah, I was just checking that how should I interpret that ? right, so objdump -R and then you have to know which relocs indicate its undefined such as R_386_COPY and R_X86_64_COPY yay arch-specificity meaning what? $ objdump -T -p -m -f -R /lib/libc.so.6 |grep optarg 0014c3c4 gDO .bss 0004 GLIBC_2.0 optarg 00148fe8 R_386_GLOB_DAToptarg $ that's a dynamic reloc, no? at least, it shows up only under -R -R are the dynamic relocs. so where is optarg defined ? :) GLOB_DAT seems to be saying something about the GOT. buxy: in libc.so.6, I guess... But I need to read it a few times before I understand I think. <-- aike est parti (Quit: Leaving) buxy: .dynsym also contains an optarg@@GLIBC_2.2.5 seen how? .dynsym is -T no ? but I don't see it I'm still a bit confused. But it's in .bss yes. I was looking with readelf, which shows: 1243: 0035cde0 8 OBJECT GLOBAL DEFAULT 33 optarg@@GLIBC_2.2.5 Where the "33" is .bss So, it's just an unintiliased global variable? Q_: sound reasonable for optarg possibly, but what does it mean to have the symbols defined on both sides ? And the relocation is just something else that wants to use it. buxy: It's a copy relocation, like most variables. and how I can differentiate it from the libXaw case where I need to find out that the binary really needs a symbol that comes from libXaw ? because xbuffy has the copy relocation, and libXaw doesn't the copy relocation, AFAIU, is what tells ld.so to go looking for the matching symbol What the copy relocation does it copy the pointer in your .bss Since it can't go thru a GOT or simular for it. okay, so I should parse -R find symbols with R_*_COPY relocations and consider looking for a corresponding symbol in the libs well, that's my understanding, but I'm not sure how to parse what Q_ said buxy: I think you can look at all relocations. Hmm, or not. Q_: I don't think I can reasonably do that... what does it mean for me to look for optarg while scanning libc6 ? :) buxy: I don't understand your last question. Q_: currently the symbols like optarg with .bss in objdump -T are considered as defined and are thus output in DEBIAN/symbols files, so it means that I consider that libraries provide them I think you should just look for a defined symbol, like you do with the other undefined symbols. except that I don't look in the current binary at all Oh, in case of a copy relocation it's not defined. awesome: configure.ac: CFLAGS="$CFLAGS -O3" It's a copy from what's in a library. so you agree that I should handle differently symbols listed in -R depending on the type
Bug#363323: dpkg-gencontrol: support multiple -T options
On Tue, 18 Apr 2006, Peter Eisentraut wrote: > It would be useful in some cases if dpkg-gencontrol could read > substitution variables from multiple files. So letting -T > options accumulate rather than overwrite each other would be nice. What is this use case precisely? Given that you can add multiple substitution variables to the same file, I'm wondering why you'd prefer having multiple files. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Bug#454036: dpkg-dev: dpkg-shlibdeps misses symbols and thus outputs false warnings
Sorry for my late reply. Somehow the mail did not reach me. (perhaps some spam filtering gone wild...) * Cyril Brulebois <[EMAIL PROTECTED]> [071226 05:03]: > "Bernhard R. Link" <[EMAIL PROTECTED]> (02/12/2007): > The point here is "-r". Both symbols are defined in > /usr/lib/libXaw7.so.7.0.0, which gets recursively pulled in through > libXaw; so I guess that dpkg-shlibdeps would like you > to link against libXaw7 directly instead of linking against libXaw. Sorry, I don't understand you. The binary links against libXaw.so.7 and it needs to (as ldd's errors show when replacing the needed header in the binary manually with libYaw. Any recursivity of ldd canot make any difference, as libXaw is not used by other libraries but vice versa). Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386
On Thu, 03 Jan 2008, Matthias Klose wrote: > > I checked the Debian Changelog but couldn't find any reference why this > > dependency was added. Please revert this change again. > > This seems to be new behaviour of dpkg-shlibdeps: Indeed, I investigated this with Matthias and dpkg-shlibdeps picks the wrong symbols file when trying to generate the dependency on libstdc++6 as proven by this log: > Library libgcc_s.so.1 found in debian/libgcc1/lib/libgcc_s.so.1 > No associated package found for debian/libgcc1/lib/libgcc_s.so.1 > Using symbols file debian/lib64gcc1/DEBIAN/symbols for libgcc_s.so.1 I have a fix in my git repo. I'm doing some test and will push it to the main repo. I will see with Guillem if we can do an upload to get this fixed in unstable soonish. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
Processed: found 458860 in 1.14.14 ..., user [EMAIL PROTECTED], usertagging 458860 ... ...
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.11 > found 458860 1.14.14 Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386 Bug marked as found in version 1.14.14. > retitle 458860 dpkg-shlibdeps: chooses bad symbols files when there's several > providing the same soname Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386 Changed Bug title to `dpkg-shlibdeps: chooses bad symbols files when there's several providing the same soname' from `libstdc++6: Dependency on lib64gcc1 on i386'. > user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). > usertags 458860 + dpkg-shlibdeps Bug#458860: dpkg-shlibdeps: chooses bad symbols files when there's several providing the same soname There were no usertags set. Usertags are now: dpkg-shlibdeps. > block 458894 with 458860 Bug#458860: dpkg-shlibdeps: chooses bad symbols files when there's several providing the same soname Bug#458894: libstdc++6: Dependency on lib64gcc1 on i386 Was not blocked by any bugs. Blocking bugs of 458894 added: 458860 > unblock 458860 with 458894 Bug#458894: libstdc++6: Dependency on lib64gcc1 on i386 Bug#458860: dpkg-shlibdeps: chooses bad symbols files when there's several providing the same soname Was blocked by: 458894 Blocking bugs of 458860 removed: 458894 > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386
Processing commands for [EMAIL PROTECTED]: > clone 458860 -1 Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386 Bug 458860 cloned as bug 458894. > reassign 458860 dpkg-dev Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386 Bug reassigned from package `libstdc++6' to `dpkg-dev'. > block 458860 by -1 Bug#458894: libstdc++6: Dependency on lib64gcc1 on i386 Bug#458860: libstdc++6: Dependency on lib64gcc1 on i386 Was not blocked by any bugs. Blocking bugs of 458860 added: 458894 > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#108587: is it you? jennie here
Do not ignore me please, I found your email somewhere and now decided to write you. Let me know if you do not mind. If you want I can send you some pictures of me. I am a nice pretty girl. Don't reply to this email. Email me direclty at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
