Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#39 Conflicting return types of function mm_support

reproducible
pending
None
1
2014-06-05
2014-05-25
No

During a rebuild of all Debian packages in a clean sid chroot (and
cowbuilder+pbuilder) the build failed with the following error. Please note
that we use our research compiler tool-chain (using tools from the cbmc
package), which permits extended reporting on type inconsistencies at link
time.

[...]
Linking CXX shared library libkwave.so

error: conflicting function declarations "mm_support"
old definition in module cputest file /srv/jenkins-slave/workspace/sid-goto-cc-kwave/kwave-0.8.11-1/libkwave/cputest.c line 62
unsigned int (void)
new definition in module memcpy file /srv/jenkins-slave/workspace/sid-goto-cc-kwave/kwave-0.8.11-1/libkwave/memcpy.c line 69
signed int (void)

libkwave/CMakeFiles/libkwave.dir/build.make:2370: recipe for target 'libkwave/libkwave.so.0.8.11' failed
make[3]: [libkwave/libkwave.so.0.8.11] Error 1
make[3]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-kwave/kwave-0.8.11-1/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:376: recipe for target 'libkwave/CMakeFiles/libkwave.dir/all' failed
make[2]:
[libkwave/CMakeFiles/libkwave.dir/all] Error 2

It seems both the forward declaration in memcpy.c as well as the declaration of
rval here

http://sources.debian.net/src/kwave/0.8.11-1-1/libkwave/cputest.c?hl=64#L62

should be fixed to be unsigned. This will ensure that future CPU ids do not
introduce undefined behaviour (at present, the code should work ok as only a
small number of bits is used).

Best,
Michael

Discussion

    • status: open --> pending
    • assigned_to: Thomas Eschenbacher
    • Group: cosmetic --> on_todo-list_for_next_version
     
  • Hello Michael,

    thanks for the report. I have taken a look on it and you are right, this was not correct. Additionally that piece of code was quite old, so instead of fixing it, I replaced it with fresh code from xine-lib which should not have this problem.

    The change is aleady in git, would it be possible for you to cross-check if that new version works/compiles as expected?

    kind regards,
    Thomas

     
  • should be fixed in v0.8.12 (released yesterday)

     
    • Group: on_todo-list_for_next_version --> reproducible