[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: request to rebuild my package libcork (FTBFS on landau, but was built OK on andi)

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:


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


Attachment: 0011-unaligned-access.patch
Description: Binary data

Reply to: