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.