Undefined references when linking to C library

wrzosk dprogr at gmail.com
Thu Dec 23 15:12:34 PST 2010


On 23.12.2010 20:38, Peter Federighi wrote:
> Jonathan M Davis wrote:
>> Did you wrap the C declarations in an extern(C) block? Without that, it's going
>> to think that your variables are D variables not C variables. The same goes for
>> any functions - _especially_ for the functions. In fact, a large portion of - in
>> not all of - your gpm.d file should likely be in extern(C).
>
> I tried "extern (C)" for the whole module and individually.  I get the following
> error:
> /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
> _gpm_arg: TLS reference in gev.o mismatches non-TLS definition in
> /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so section .data
> /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so: could not read
> symbols: Bad value
> collect2: ld returned 1 exit status
> --- errorlevel 1
>
> Is this a 32/64 bit issue?  I have both versions of libgpm installed.  Those file
> paths are obtuse, but they do point to the 32 bit libraries.  I've successfully
> compiled other programs that use C libraries such as SDL and OpenGL (both via the
> Derelict2 modules).
>
> I also tried htod and compared the output with what I wrote.  The differences are
> inconsequential.
>
> Thank you,
> - Peter Federighi

I've had simmilar issue a few days ago. The problem is that global 
values from C should be marked shared in D

extern int val; -> extern (C) shared int val;

or maybe __gshared. Both makes linking stage finishes with success.


More information about the Digitalmars-d-learn mailing list