Hi Roger,
> On 3 Aug 2016, at 05:13, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>
> Hi Roger!
>
> Sorry for not replying earlier, I must have missed your mail.
>
> Please always direct any sparc-related issues to debian-sparc@l.d.o.
>
> On 07/29/2016 12:19 PM, Roger Shimizu wrote:
>> My package libcork was built OK (version -5) on andi but latest
>> (version -6) is FTBFS on landau [0].
>
> Probably -5 was built with "nocheck" enabled. It's definitely not a hw issue.
>
>> version -6 build was failed on unit test after compiling, and the
>> error message is "Bus error", which I don't understand and it doesn't
>> occur on other archs:
>> (...)
>> ====
>> +++ /<<BUILDDIR>>/libcork-0.15.0+ds/tests/cork-hash.t.err
>> @@ -5,6 +5,8 @@
>> $ cork-hash bar
>> 0x450e998d
>> $ cork-hash tests.h
>> - 0x0b0628ee
>> + Bus error
>> + [138]
>> $ cork-hash "A longer string"
>> - 0x53a2c885
>> + Bus error
>> + [138]
>> ====
>
>
> It's a bus error which occurs when your code tries an unaligned access.
>
> Most likely you have something like "a = *(foo_t *) b;" in your code which
> triggers the unaligned memory access. To eliminate the problem, use
> memcpy to copy the contents from one variable to another in this case
> or use macros which ensure aligned access, see for example [1].
>
> The reason why this issue doesn't show on other architectures is because
> most other architectures don't trigger an exception on unaligned access,
> although SuperH (sh4) sometimes does this as well.
>
> Either way, unaligned access usually speaks for bad code and you should
> therefore fix the bug in question. You can do this on notker [2] with
> the help of gdb.
>
> If you have more questions, send them to the mailing list.
I had a look and found the unaligned accesses, and have attached a fix.
Whilst building the package, I couldn’t help but notice that libcork15 contains
libcork.so.15, which is a symlink to libcork.so.16.0.1. This is clearly very
very wrong (package name should be bumped up to libcork16, and the symlink
should be called libcork.so.16). The cause of this is a crazy calculation in
upstream’s cmake/FindCTargets.cmake, where on line 66 it does:
math(EXPR __SOVERSION "${__VERSION_CURRENT} - ${__VERSION_AGE}”)
This is then used to create the libcork.so.$__SOVERSION symlink, and given that
__VERSION_CURRENT is 16 and __VERSION_AGE is 1, it calculates 16-1=15.
__SOVERSION and __VERSION_CURRENT should be the same thing. Please request a
transition, patch FindCTargets.cmake, bump the package name up to libcork16,
upload the fixed version and file binNMUs. And, of course, get upstream
patched.
Regards,
James
Attachment:
0011-unaligned-access.patch
Description: Binary data