www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - deimos libX11 undefined reference

reply "cal" <callumenator gmail.com> writes:
I'm using the deimos libX11 bindings, DMD 2.058 OpenSUSE x86_64.

In Xlibint.d, my linker can't resolve '_XData16' (it's proto is 
on line 624 of Xlibint).

Does anyone who knows X11 know what library I should be linking 
to for that function? Or an easy way to grep the symbols in a 
directory of libraries in linux (I mostly use windows...).

Cheers
Jul 11 2012
next sibling parent reply "cal" <callumenator gmail.com> writes:
On Wednesday, 11 July 2012 at 23:18:25 UTC, cal wrote:
 I'm using the deimos libX11 bindings, DMD 2.058 OpenSUSE x86_64.

 In Xlibint.d, my linker can't resolve '_XData16' (it's proto is 
 on line 624 of Xlibint).

 Does anyone who knows X11 know what library I should be linking 
 to for that function? Or an easy way to grep the symbols in a 
 directory of libraries in linux (I mostly use windows...).

 Cheers

Hmm, looking at the .c header, the function is not even defined. I think it is not used, and in this case turning macros into functions in the binding generates linker errors. I don't know the best way to fix this in the binding (I have simply commented out the functions in my repo, as they don't seem to be used). But its worth noting.
Jul 11 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-12 01:50, cal wrote:

 Hmm, looking at the .c header, the function is not even defined. I think
 it is not used, and in this case turning macros into functions in the
 binding generates linker errors. I don't know the best way to fix this
 in the binding (I have simply commented out the functions in my repo, as
 they don't seem to be used). But its worth noting.

If a macro is turned into a function it needs to have an implementation. -- /Jacob Carlborg
Jul 11 2012
parent mta`chrono <chrono mta-international.net> writes:
Am 12.07.2012 08:17, schrieb Jacob Carlborg:
 On 2012-07-12 01:50, cal wrote:
 
 Hmm, looking at the .c header, the function is not even defined. I think
 it is not used, and in this case turning macros into functions in the
 binding generates linker errors. I don't know the best way to fix this
 in the binding (I have simply commented out the functions in my repo, as
 they don't seem to be used). But its worth noting.

If a macro is turned into a function it needs to have an implementation.

when marcos are turned into functions they introduce new symbols. it's a pity, but in that case you have to link to deimos. so deimos will become a wrapper rather than a binding.
Jul 12 2012
prev sibling parent Ed McCardell <edmccard hotmail.com> writes:
On 07/11/2012 07:50 PM, cal wrote:
 On Wednesday, 11 July 2012 at 23:18:25 UTC, cal wrote:
 I'm using the deimos libX11 bindings, DMD 2.058 OpenSUSE x86_64.

 In Xlibint.d, my linker can't resolve '_XData16' (it's proto is on
 line 624 of Xlibint).

 Does anyone who knows X11 know what library I should be linking to for
 that function? Or an easy way to grep the symbols in a directory of
 libraries in linux (I mostly use windows...).

 Cheers

Hmm, looking at the .c header, the function is not even defined. I think it is not used, and in this case turning macros into functions in the binding generates linker errors. I don't know the best way to fix this in the binding (I have simply commented out the functions in my repo, as they don't seem to be used). But its worth noting.

_XData16 should only be used when WORD64 is defined, and (from Xtos.h) #ifdef CRAY #define WORD64 #endif WORD64 should only be defined when building on a Cray. I've sent a pull request to the deimos/x11 repo. --Ed
Jul 15 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 12 July 2012 at 16:43:28 UTC, mta`chrono wrote:
 when marcos are turned into functions they introduce new 
 symbols. it's a
 pity, but in that case you have to link to deimos. so deimos 
 will become
 a wrapper rather than a binding.

The binding author can also opt to just translate them to template functions (possibly taking no template parameter). This way, the bodies are emitted into every translation unit which uses them, removing the need to link against the Deimos "headers". The libevent and OpenSSL bindings, which I contributed, use this approach. David
Jul 12 2012
prev sibling next sibling parent "cal" <callumenator gmail.com> writes:
On Thursday, 12 July 2012 at 16:43:28 UTC, mta`chrono wrote:
 Am 12.07.2012 08:17, schrieb Jacob Carlborg:
 On 2012-07-12 01:50, cal wrote:
 
 Hmm, looking at the .c header, the function is not even 
 defined. I think
 it is not used, and in this case turning macros into 
 functions in the
 binding generates linker errors. I don't know the best way to 
 fix this
 in the binding (I have simply commented out the functions in 
 my repo, as
 they don't seem to be used). But its worth noting.

If a macro is turned into a function it needs to have an implementation.

when marcos are turned into functions they introduce new symbols. it's a pity, but in that case you have to link to deimos. so deimos will become a wrapper rather than a binding.

I compile the deimos bindings along with my own code, so that's not a problem. The function in question was actually proto'd as an extern, so it was expecting another library to resolve it. The original C header did not even define the function (whereas the binding does, but as an extern dependency) so it would appear that the macro was/is never used, otherwise using the .c header would introduce an undefined function. I guess macros can introduce undefined symbols as long as they are never used, but the same is only true for .d bindings if they are introduced as templates like David said.
Jul 12 2012
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
Try -L-lX11
Jul 14 2012
prev sibling parent "cal" <callumenator gmail.com> writes:
On Saturday, 14 July 2012 at 12:55:21 UTC, Minas Mina wrote:
 Try -L-lX11

Yeah I was already linking X11. The problem was the binding, it defined a function that was never defined in the original c header, so it would not be able to find the function anywhere. Commenting the defs out in the binding solved it for me.
Jul 14 2012