> Package: cxref
> Version: 1.6d-6
> Usertags: goto-cc
> 
> During a rebuild of all 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.
> 
> [...]
> gcc -Wl,-z,relro cccp.o cexp.o prefix.o version.o -o cxref-cpp 
> 
> error: conflicting function declarations "check_assertion"
> old definition in module cccp file cccp.c line 6692
> signed int (unsigned char *name, signed int sym_length, signed int 
> tokens_specified, struct arglist *tokens)
> new definition in module cexp file cexp.c line 180
> signed int (unsigned char *, signed int, signed int, struct arglist *)
> Makefile:62: recipe for target 'cxref-cpp' failed
> make[2]: *** [cxref-cpp] Error 64
> make[2]: Leaving directory 
> '/srv/jenkins-slave/workspace/sid-goto-cc-cxref/cxref-1.6d/cpp'
> Makefile:23: recipe for target 'programs' failed
> 
> While the above appear consistent at first sight, the arglist structs are
> actually different:
> 
> composite type component counts differ (6/4)
> struct arglist {
>   struct arglist * next;
>   unsigned char * name;
>   signed int length;
>   signed int argno;
>   char rest_args;
>   unsigned long <<padding>> : 56;
> }
> struct arglist {
>   struct arglist * next;
>   unsigned char * name;
>   signed int length;
>   signed int argno;
> }
> 
> What might be worse, however, is that both cccp.c and cexp.c provide 
> definitions
> (not only declarations!) of this function - with the above conflict in types.
> Depending on which of the definitions the linker decides to pick, this might 
> or
> might not go wrong.

This is an interesting finding.  The files in questions come from
gcc-2.95.3 with no modifications from me in this area.

Making the two arglist structure definitions the same is easy enough.

The question raised at the end about the definitions for this function
being repeated in each file is luckily not relevant.  There are two
definitions of the function but the one in cexp.c is enclosed within
an #ifdef/#endif that is never activated.  There can therefore only be
one function linked in.


I have committed a fix for this to subversion if it is of interest:

http://www.gedanken.org.uk/svn/cxref/

You can view the log here:

http://www.gedanken.org.uk/viewvc/cxref/trunk/?view=log

-- 
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop            http://www.gedanken.org.uk/software/cxref/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to