Undefined references when linking to C library

[Jonathan M Davis]

On Thursday 23 December 2010 11:38:28 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.

Yeah. It looks like the compiler is finding the 64-bit versions rather than the 
32-bit versions. How to fix that will likely depend on the libraries in question 
and on how your system is set up. Obviously, a 32-bit chroot environment would 
fix the problem, but that's also obviously not a pleasant, or even necessarily 
simple, solution.

I'm not really all that well-versed in dealing with linking issues like this, 
but I'd say that either the compiler is just not finding the 32-bit versions, 
because of a messed up or missing path, or you need to be linking separately 
because you're on a 64-bit system (which I don't _think_ is the case, but it 
might be). Regardless, you can try compiling all of the code with -c and then 
linking it with gcc directly (probably with -m32).

Unfortunately, while I do run a 64-bit environment, due to problems with Arch 
and multilib systems, I've generally had to run dmd in a chrooted environment, 
and you don't have to deal with the 32-bit vs 64-bit issues with that, so I 
don't have much experience with this sort of problem. Regardless, I'll be very 
glad when the 64-bit port of dmd is completed.

- Jonathan M Davis