Your message dated Mon, 31 Aug 2009 23:25:27 -0700
with message-id <[email protected]>
and subject line Re: unixodbc: FTBFS (ppc64): incorrect soname libgtrtst.so.1,
missing symbol: Base GetRCString
has caused the Debian Bug report #360712,
regarding unixodbc: FTBFS (ppc64): incorrect soname libgtrtst.so.1, missing
symbol: Base GetRCString
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
360712: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360712
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: unixodbc
Version: 2.2.11-12
Severity: normal
Hello,
when building 'unixodbc' on ppc64/unstable, I get the following error:
dh_fixperms
dh_fixperms: Compatibility levels before 4 are deprecated.
perl ./debian/dh_makeshlibs -X lib/odbc/lib -a
dh_makeshlibs: Compatibility levels before 4 are deprecated.
Error: incorrect soname libgtrtst.so.1, missing symbol: Base GetRCString
make: *** [binary-arch] Error 255
This seems to be caused by a difference in the output of 'objdump -T'
on ppc64 compared to other architectures (see Bug#354809 for a
discussion of the related problem with the symbol versioning feature
of db4.4 and other packages).
A sample 'objdump -T' output on ppc64 looks like this:
# objdump -T debian/unixodbc/usr/lib/libgtrtst.so.1.0.0
debian/unixodbc/usr/lib/libgtrtst.so.1.0.0: file format elf64-powerpc
DYNAMIC SYMBOL TABLE:
0000000000000780 l d .init 0000000000000000 .init
00000000000007b0 l d .text 0000000000000000 .text
0000000000000c30 l d .fini 0000000000000000 .fini
0000000000000c58 l d .rodata 0000000000000000 .rodata
0000000000000c68 l d .eh_frame 0000000000000000 .eh_frame
0000000000011000 l d .ctors 0000000000000000 .ctors
0000000000011010 l d .dtors 0000000000000000 .dtors
0000000000011020 l d .jcr 0000000000000000 .jcr
0000000000011028 l d .data.rel.ro 0000000000000000
.data.rel.ro
00000000000111d8 l d .data 0000000000000000 .data
00000000000111e8 l d .opd 0000000000000000 .opd
0000000000011388 l d .bss 0000000000000000 .bss
0000000000000000 w DF *UND* 00000000000001d0 GLIBC_2.3 __cxa_finalize
0000000000000000 DF *UND* 00000000000000e8 GLIBC_2.3 vsprintf
0000000000011260 g DF .opd 00000000000000c8 Base szLogPrintf
0000000000011278 g DF .opd 00000000000000d8 Base szMessageBox
0000000000011290 g DF .opd 0000000000000038 Base GetRCString
0000000000000000 DF *UND* 000000000000027c GLIBC_2.3 puts
0000000000000000 w D *UND* 0000000000000000
_Jv_RegisterClasses
0000000000000000 w D *UND* 00000000000
Note that in some lines there is a '.opd' shown in the 4th column
where for other architectures there would be a '.text'.
This is due to a peculiarity in the binary object format on ppc64.
There was a suggestion that the 'objdump -T' format difference on ppc64
should be considered as a binutils bug. I am not sure about that.
The binary object format on ppc64 _is_ different after all and the
'objdump -T' seems to reflect that difference correctly.
I do not know how to fix this problem.
Regards
Andreas Jochens
--- End Message ---
--- Begin Message ---
Version: 2.2.11-17
unixodbc now uses dpkg-shlibdeps, so if unixodbc still fails to build on
ppc64, that should be treated as a bug in dpkg-shlibdeps (or in objdump).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
[email protected] [email protected]
signature.asc
Description: Digital signature
--- End Message ---
