Thread overview
deimos libX11 undefined reference
Jul 11, 2012
cal
Jul 11, 2012
cal
Jul 12, 2012
Jacob Carlborg
Jul 12, 2012
mta`chrono
Jul 12, 2012
David Nadlinger
Jul 12, 2012
cal
Jul 14, 2012
Minas Mina
Jul 14, 2012
cal
Jul 15, 2012
Ed McCardell
July 11, 2012
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

July 11, 2012
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.

July 12, 2012
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
July 12, 2012
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.
July 12, 2012
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
July 12, 2012
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.
July 14, 2012
Try -L-lX11
July 14, 2012
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.
July 15, 2012
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