Bug#354809: [Pkg-db-devel] Bug#354809: db4.4: FTBFS (ppc64): syntax error in VERSION script
* Andreas Jochens: Looking at the attached two outputs of 'objdump -t' for the file 'obj/.libs/db185.o' on ppc64 and amd64 it appears that the symbols that are in the '.text' section on amd64 are in a section named '.opd' on ppc64. That's because ppc64 uses function descriptors. It would probably make sense for binutils to mostly hide this distinction (unless there is a compelling reason not to do it). I am not an object file format expert at all, but I would take this as an indication that the current method of parsing of the nm output to create the Versions script is not really portable. I still think this should be addressed in nm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354809: [Pkg-db-devel] Bug#354809: db4.4: FTBFS (ppc64): syntax error in VERSION script
Hello, On 06-Mar-01 23:16, Florian Weimer wrote: * Andreas Jochens: Looking at the output of 'nm' I found that the symbols which are marked with 'T' on other architectures have a 'D' on ppc64 instead. However, there are also symbols which have a 'D' on other architectures and on ppc64 as well. I do not know how to filter out the correct list of symbols for the 'global:' section on ppc64. This smells like a binutils bug. The documentation is quite clear; * The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is local; if uppercase, the symbol is global (external). [...] `D' The symbol is in the initialized data section. [...] `T' The symbol is in the text (code) section. Or is the ppc64 documentation different? not the documentation but the object file format indeed seems to be different on ppc64. Looking at the attached two outputs of 'objdump -t' for the file 'obj/.libs/db185.o' on ppc64 and amd64 it appears that the symbols that are in the '.text' section on amd64 are in a section named '.opd' on ppc64. I am not an object file format expert at all, but I would take this as an indication that the current method of parsing of the nm output to create the Versions script is not really portable. Regards Andreas Jochens ppc64:db4.4-4.4.20/obj/.libs# objdump -t db185.o db185.o: file format elf64-powerpc SYMBOL TABLE: ldf *ABS* db185.c ld .text .text ld .data .data ld .bss .bss ld .toc .toc ld .debug_abbrev .debug_abbrev ld .debug_info .debug_info ld .debug_line .debug_line ld .rodata.str1.8 .rodata.str1.8 00d8 l F .opd 0080 db185_prefix 00c0 l F .opd 0080 db185_compare 00f0 l F .opd 0054 db185_hash 0018 l F .opd 009c db185_close 0030 l F .opd 010c db185_del 0048 l F .opd 006c db185_fd 0060 l F .opd 0120 db185_get 0078 l F .opd 03c0 db185_put 0090 l F .opd 01b0 db185_seq 00a8 l F .opd 00dc db185_sync ld .opd .opd ld .debug_frame .debug_frame ld .debug_loc .debug_loc ld .debug_pubnames .debug_pubnames ld .debug_aranges .debug_aranges ld .debug_str .debug_str ld .comment .comment g F .opd 0754 __db185_open *UND* db_create *UND* __os_calloc *UND* __os_free *UND* __os_set_errno *UND* __db_oflags *UND* __os_exists *UND* __os_openhandle *UND* __os_closehandle amd64:db4.4-4.4.20/obj/.libs# objdump -t db185.o db185.o: file format elf64-x86-64 SYMBOL TABLE: ldf *ABS* db185.c ld .text .text ld .data .data ld .bss .bss ld .debug_abbrev .debug_abbrev ld .debug_info .debug_info ld .debug_line .debug_line ld .rodata.str1.8 .rodata.str1.8 ld .rodata.str1.1 .rodata.str1.1 0c00 l F .text 003a db185_prefix 0bc0 l F .text 003a db185_compare 0590 l F .text 004f db185_close 05e0 l F .text 009b db185_del 0680 l F .text 0034 db185_fd 06c0 l F .text 00c4 db185_get 0790 l F .text 0278 db185_put 0a10 l F .text 0136 db185_seq 0b50 l F .text 006e db185_sync 0c40 l F .text 0016 db185_hash
Bug#354809: [Pkg-db-devel] Bug#354809: db4.4: FTBFS (ppc64): syntax error in VERSION script
Andreas Jochens wrote: The attached patch disables the use of the Versions script on ppc64. With this patch 'db4.4' can be compiled on ppc64. Surely, there must be a way to resolve this bug without disabling versioned symbols on ppc64... Given the number of packages in the distribution that link twice to libdb, via transient library dependencies, versioned symbols are pretty much a must. ... Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354809: [Pkg-db-devel] Bug#354809: db4.4: FTBFS (ppc64): syntax error in VERSION script
Hello, thank you for your reply to my report! On 06-Mar-01 22:24, Adam Conrad wrote: Andreas Jochens wrote: The attached patch disables the use of the Versions script on ppc64. With this patch 'db4.4' can be compiled on ppc64. Surely, there must be a way to resolve this bug without disabling versioned symbols on ppc64... Given the number of packages in the Of course, but I do not know how to do this properly. Looking at the output of 'nm' I found that the symbols which are marked with 'T' on other architectures have a 'D' on ppc64 instead. However, there are also symbols which have a 'D' on other architectures and on ppc64 as well. I do not know how to filter out the correct list of symbols for the 'global:' section on ppc64. There are other packages that have the same problem on ppc64, e.g. cyrus-sasl2, libdebian-installer and of course the other dbx.y packages. Currently the ppc64 port uses patched versions of these packages which disable the version scripts entirely. Any suggestions how to fix this properly are welcome. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354809: [Pkg-db-devel] Bug#354809: db4.4: FTBFS (ppc64): syntax error in VERSION script
* Andreas Jochens: Looking at the output of 'nm' I found that the symbols which are marked with 'T' on other architectures have a 'D' on ppc64 instead. However, there are also symbols which have a 'D' on other architectures and on ppc64 as well. I do not know how to filter out the correct list of symbols for the 'global:' section on ppc64. This smells like a binutils bug. The documentation is quite clear; * The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is local; if uppercase, the symbol is global (external). [...] `D' The symbol is in the initialized data section. [...] `T' The symbol is in the text (code) section. Or is the ppc64 documentation different? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
