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#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: vorlon buxy: 454036: definitely a dpkg-dev bug, data symbols should also be part of the list being checked [...] buxy the bug log has has the relevant objdump output on the binary vorlon right Q_ The problem being it's a copy relocation? vorlon yes, seems so vorlon Q_: do you know of any case when there should be an exported symbol in .bss that /isn't/ a copy relocation? Q_ I have no idea. vorlon ok vorlon buxy: my guess is that it's reasonable, at least as a next pass, to treat all .bss symbols you find as unresolved symbols vorlon if we find exceptions, we can sort those out after : But after some more reseach it appeared that it's not really reasonable: buxy vorlon: I don't think I can consider dynamic symbols marked contained in .bss as undefined... buxy 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 buxy and undefined on both sides doesn't make sense vorlon buxy: ah, neat :) Q_ buxy: In libc6 it also has a relocation: R_X86_64_GLOB_DAT optarg buxy Q_: yeah, I was just checking that how should I interpret that ? vorlon 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 vorlon 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 Q_ -R are the dynamic relocs. buxy so where is optarg defined ? :) Q_ GLOB_DAT seems to be saying something about the GOT. vorlon buxy: in libc.so.6, I guess... Q_ But I need to read it a few times before I understand I think. -- aike est parti (Quit: Leaving) Q_ buxy: .dynsym also contains an optarg@@GLIBC_2.2.5 vorlon seen how? buxy .dynsym is -T no ? but I don't see it Q_ 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? noshadow Q_: sound reasonable for optarg buxy possibly, but what does it mean to have the symbols defined on both sides ? Q_ And the relocation is just something else that wants to use it. Q_ buxy: It's a copy relocation, like most variables. buxy 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 ? vorlon 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 Q_ What the copy relocation does it copy the pointer in your .bss Since it can't go thru a GOT or simular for it. buxy okay, so I should parse -R find symbols with R_*_COPY relocations and consider looking for a corresponding symbol in the libs vorlon well, that's my understanding, but I'm not sure how to parse what Q_ said Q_ buxy: I think you can look at all relocations. Q_ Hmm, or not. buxy Q_: I don't think I can reasonably do that... what does it mean for me to look for optarg while scanning libc6 ? :) Q_ buxy: I don't understand your last question. buxy 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 Q_ I think you should just look for a defined symbol, like you do with the other undefined symbols. buxy except that I don't look in the current binary at all Q_ Oh, in case of a copy relocation it's not defined. edmonds awesome:
Bug#454036: dpkg-dev: dpkg-shlibdeps misses symbols and thus outputs false warnings
Bernhard R. Link [EMAIL PROTECTED] (02/12/2007): dpkg-shlibdeps misses some symbols and thus prints warnings about not using symbols from a library even when doing so. Yes, it does in some cases, but I'm not sure it is the case here. but when I edit the binary to change the NEEDED section I get: | $ ldd -r debian/xbuffy/usr/bin/xbuffy | libYaw.so.7 = not found | libXt.so.6 = /usr/lib/libXt.so.6 (0xf7eb8000) | libX11.so.6 = /usr/lib/libX11.so.6 (0xf7db4000) | libc.so.6 = /lib/libc.so.6 (0xf7c4) | libSM.so.6 = /usr/lib/libSM.so.6 (0xf7c28000) | libICE.so.6 = /usr/lib/libICE.so.6 (0xf7c0) | libXau.so.6 = /usr/lib/libXau.so.6 (0xf7bec000) | libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0xf7bd8000) | libdl.so.2 = /lib/libdl.so.2 (0xf7bc) | /lib/ld-linux.so.2 (0xf7f2c000) | undefined symbol: boxWidgetClass (debian/xbuffy/usr/bin/xbuffy) | undefined symbol: commandWidgetClass (debian/xbuffy/usr/bin/xbuffy) 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. I'm missing a i386 unstable currently, but looking there at the binary in etch, I think this will not be sparc specific at all. I gathered the above on i386. Nothing sparc-specific AFAICS. Cheers, -- Cyril Brulebois signature.asc Description: Digital signature
Bug#454036: dpkg-dev: dpkg-shlibdeps misses symbols and thus outputs false warnings
Package: dpkg-dev Version: 1.14.12 Severity: minor dpkg-shlibdeps misses some symbols and thus prints warnings about not using symbols from a library even when doing so. When compiling xbuffy-3.3.bl.3.dfsg-5 I get the following warning: | dpkg-shlibdeps: warning: debian/xbuffy/usr/bin/xbuffy shouldn't be | linked with libXaw.so.7 (it uses none of its symbols). but when I edit the binary to change the NEEDED section I get: | $ ldd -r debian/xbuffy/usr/bin/xbuffy | libYaw.so.7 = not found | libXt.so.6 = /usr/lib/libXt.so.6 (0xf7eb8000) | libX11.so.6 = /usr/lib/libX11.so.6 (0xf7db4000) | libc.so.6 = /lib/libc.so.6 (0xf7c4) | libSM.so.6 = /usr/lib/libSM.so.6 (0xf7c28000) | libICE.so.6 = /usr/lib/libICE.so.6 (0xf7c0) | libXau.so.6 = /usr/lib/libXau.so.6 (0xf7bec000) | libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0xf7bd8000) | libdl.so.2 = /lib/libdl.so.2 (0xf7bc) | /lib/ld-linux.so.2 (0xf7f2c000) | undefined symbol: boxWidgetClass (debian/xbuffy/usr/bin/xbuffy) | undefined symbol: commandWidgetClass (debian/xbuffy/usr/bin/xbuffy) 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 | 0002810c R_SPARC_GLOB_DAT __gmon_start__ | 00028110 R_SPARC_GLOB_DAT _Jv_RegisterClasses | 00028120 R_SPARC_GLOB_DAT __cxa_finalize | 00028a40 R_SPARC_COPY boxWidgetClass | 00028a48 R_SPARC_COPY stderr | 00028a50 R_SPARC_COPY XtShellStrings | 00028f60 R_SPARC_COPY XtStrings | 000299bc R_SPARC_COPY transientShellWidgetClass | 000299c0 R_SPARC_COPY commandWidgetClass | 00028154 R_SPARC_JMP_SLOT fputs | 00028160 R_SPARC_JMP_SLOT __errno_location | 0002816c R_SPARC_JMP_SLOT connect | 00028178 R_SPARC_JMP_SLOT XtGetValues | 00028184 R_SPARC_JMP_SLOT XtRealizeWidget | 00028190 R_SPARC_JMP_SLOT XtSetValues | 0002819c R_SPARC_JMP_SLOT __xstat | 000281a8 R_SPARC_JMP_SLOT __gmon_start__ | 000281b4 R_SPARC_JMP_SLOT XtCreatePopupShell | 000281c0 R_SPARC_JMP_SLOT XtTranslateCoords | 000281cc R_SPARC_JMP_SLOT realloc | 000281d8 R_SPARC_JMP_SLOT strchr | 000281e4 R_SPARC_JMP_SLOT getenv | 000281f0 R_SPARC_JMP_SLOT system | 000281fc R_SPARC_JMP_SLOT putchar | 00028208 R_SPARC_JMP_SLOT fgets | 00028214 R_SPARC_JMP_SLOT memset | 00028220 R_SPARC_JMP_SLOT __libc_start_main | 0002822c R_SPARC_JMP_SLOT execl | 00028238 R_SPARC_JMP_SLOT _IO_getc | 00028244 R_SPARC_JMP_SLOT _exit | 00028250 R_SPARC_JMP_SLOT strrchr | 0002825c R_SPARC_JMP_SLOT perror | 00028268 R_SPARC_JMP_SLOT XtPopdown | 00028274 R_SPARC_JMP_SLOT XtConvert | 00028280 R_SPARC_JMP_SLOT readdir | 0002828c R_SPARC_JMP_SLOT XtRemoveTimeOut | 00028298 R_SPARC_JMP_SLOT strtol | 000282a4 R_SPARC_JMP_SLOT fdopen | 000282b0 R_SPARC_JMP_SLOT free | 000282bc R_SPARC_JMP_SLOT XtAppInitialize | 000282c8 R_SPARC_JMP_SLOT XtAppMainLoop | 000282d4 R_SPARC_JMP_SLOT access | 000282e0 R_SPARC_JMP_SLOT XBell | 000282ec R_SPARC_JMP_SLOT setpriority | 000282f8 R_SPARC_JMP_SLOT fflush | 00028304 R_SPARC_JMP_SLOT opendir | 00028310 R_SPARC_JMP_SLOT socket | 0002831c R_SPARC_JMP_SLOT __ctype_b_loc | 00028328 R_SPARC_JMP_SLOT fseek | 00028334 R_SPARC_JMP_SLOT fclose | 00028340 R_SPARC_JMP_SLOT bcopy | 0002834c R_SPARC_JMP_SLOT XtDestroyWidget | 00028358 R_SPARC_JMP_SLOT XtDisplay | 00028364 R_SPARC_JMP_SLOT sscanf | 00028370 R_SPARC_JMP_SLOT strlen | 0002837c R_SPARC_JMP_SLOT fopen | 00028388 R_SPARC_JMP_SLOT waitpid | 00028394 R_SPARC_JMP_SLOT feof | 000283a0 R_SPARC_JMP_SLOT strcpy | 000283ac R_SPARC_JMP_SLOT XtGetApplicationResources | 000283b8 R_SPARC_JMP_SLOT printf | 000283c4 R_SPARC_JMP_SLOT XCreateBitmapFromData | 000283d0 R_SPARC_JMP_SLOT closedir | 000283dc R_SPARC_JMP_SLOT fwrite | 000283e8 R_SPARC_JMP_SLOT XtAppAddTimeOut | 000283f4 R_SPARC_JMP_SLOT fprintf | 00028400 R_SPARC_JMP_SLOT malloc | 0002840c R_SPARC_JMP_SLOT XtIsRealized | 00028418 R_SPARC_JMP_SLOT XtAddEventHandler | 00028424 R_SPARC_JMP_SLOT fputc | 00028430 R_SPARC_JMP_SLOT strtok | 0002843c R_SPARC_JMP_SLOT XtPopup | 00028448 R_SPARC_JMP_SLOT strncasecmp | 00028454 R_SPARC_JMP_SLOT __ctype_tolower_loc | 00028460 R_SPARC_JMP_SLOT strcat | 0002846c R_SPARC_JMP_SLOT puts | 00028478 R_SPARC_JMP_SLOT fork | 00028484 R_SPARC_JMP_SLOT utimes | 00028490 R_SPARC_JMP_SLOT strncmp | 0002849c R_SPARC_JMP_SLOT vfprintf | 000284a8 R_SPARC_JMP_SLOT snprintf | 000284b4 R_SPARC_JMP_SLOT XtCreateManagedWidget | 000284c0 R_SPARC_JMP_SLOT kill | 000284cc R_SPARC_JMP_SLOT gethostbyname | 000284d8 R_SPARC_JMP_SLOT strcmp | 000284e4 R_SPARC_JMP_SLOT __cxa_finalize | 000284f0 R_SPARC_JMP_SLOT __strdup | 000284fc R_SPARC_JMP_SLOT exit | 00028508 R_SPARC_JMP_SLOT sprintf | 00028514 R_SPARC_JMP_SLOT _init From what I
