www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Undefined references when linking to C library

reply Peter Federighi <pfederighi yahoo.com> writes:
Hello all.

I'm writing a simple terminal game (that will eventually be turned into a
simple SDL game) and thought I would add mouse support via libgpm.  So, I
converted gpm.h into gpm.d.  Perhaps I didn't do this correctly because I get
several undefined references when trying to link.

Here's an example:
The original gpm.h says:
extern int gpm_zerobased;
extern unsigned char    _gpm_buf[];
extern unsigned short * _gpm_arg;

My gpm.d says:
extern int gpm_zerobased;
extern char*  _gpm_buf;
extern ushort* _gpm_arg;

When running 'dmd gev.d gpm.d -L-lgpm', I get:
gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x12): undefined reference to
`_D3gpm8_gpm_bufPa'
gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x26): undefined reference to
`_D3gpm13gpm_zerobasedi'
gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x34): undefined reference to
`_D3gpm8_gpm_argPt'

Does anyone have any ideas?

Thank you,
- Peter
Dec 22 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday 22 December 2010 19:25:35 Peter Federighi wrote:

 Hello all.
 
 I'm writing a simple terminal game (that will eventually be turned into a
 simple SDL game) and thought I would add mouse support via libgpm.  So, I
 converted gpm.h into gpm.d.  Perhaps I didn't do this correctly because I
 get several undefined references when trying to link.
 
 Here's an example:
 The original gpm.h says:
 extern int gpm_zerobased;
 extern unsigned char    _gpm_buf[];
 extern unsigned short * _gpm_arg;
 
 My gpm.d says:
 extern int gpm_zerobased;
 extern char*  _gpm_buf;
 extern ushort* _gpm_arg;
 
 When running 'dmd gev.d gpm.d -L-lgpm', I get:
 gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x12): undefined reference to
 `_D3gpm8_gpm_bufPa'
 gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x26): undefined reference to
 `_D3gpm13gpm_zerobasedi'
 gpm.d:(.text._D3gpm15Gpm_DrawPointerFiiiZv+0x34): undefined reference to
 `_D3gpm8_gpm_argPt'
 
 Does anyone have any ideas?



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).

You can try htod ( http://www.digitalmars.com/d/2.0/htod.html ) and see what it 
creates. It won't necessarily be correct, but it might be, and it might give
you 
a better idea of where you screwed up. It's a Windows program, but it will run 
in wine.

- Jonathan M Davis
Dec 22 2010
parent reply Peter Federighi <pfederighi yahoo.com> writes:
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
Dec 23 2010
next sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Peter Federighi wrote:

 Jonathan M Davis wrote:

 Did you wrap the C declarations in an extern(C) block? Without that, i=







 to think that your variables are D variables not C variables. The same=







 any functions - _especially_ for the functions. In fact, a large porti=







 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 =




 error:
 /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/=




 _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 =




 /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../lib/libgpm.so: could n=




 symbols: Bad value
 collect2: ld returned 1 exit status
 --- errorlevel 1
=20
 Is this a 32/64 bit issue?  I have both versions of libgpm installed.  =




 paths are obtuse, but they do point to the 32 bit libraries.  I've succ=




 compiled other programs that use C libraries such as SDL and OpenGL (bo=




 Derelict2 modules).
=20



__gshared.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Dec 23 2010
prev sibling parent reply wrzosk <dprogr gmail.com> writes:
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.
Dec 23 2010
parent Peter Federighi <pfederighi yahoo.com> writes:
wrzosk wrote:

 I've had simmilar issue a few days ago. The problem is that global values from
C




 extern int val; -> extern (C) shared int val;
 or maybe __gshared. Both makes linking stage finishes with success.



Jerome M. Berger wrote:

 I think gpm_zerobased, _bpm_buf and _gpm_arg should be declared __gshared.



Indeed.  So I added a bunch of "__gshared"s to all the variables and it compiles
and links.  Yah!  I just have to remember to declare handler functions with
extern
(C), otherwise the program will segfault once the handler returns.

Where should I post/upload the files that I converted?  There are a whole two of
them:  One is gpm.h which is specific to libgpm.  The other is paths.h which I
was
surprised to find not already available.  I would assume that it should be
available as std.c.linux.paths or core.sys.posix.paths.  Also, should the files
end with .d or .di  I may be the only person who wants to use libgpm with D,
but I
figure it should be available just in case.

Thank you all for your help.
- Peter Federighi
Dec 23 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Dec 23 2010