Shared Object with DMD v2.031

[Sergey Gromov]

Wed, 5 Aug 2009 20:46:53 +0000 (UTC), teo wrote:

> On Tue, 04 Aug 2009 18:41:50 +0400, Sergey Gromov wrote:
> 
>> Sun, 2 Aug 2009 11:18:24 +0000 (UTC), teo wrote:
>> 
>>> On Sun, 02 Aug 2009 02:18:28 +0400, Sergey Gromov wrote:
>>> 
>>>> My guess is that test.di is exactly the same as test.d because all the
>>>> functions are small.  Therefore compiling 'dmd prog.d test.di'
>>>> resolves all symbols statically and the .so is simply not linked. 
>>>> Does your 'prog' have any unresolved symbols in its symbol table?
>>> 
>>> It looks like this is the case. I found following in the symbols:
>>> 0804b8cc T _D4test6testMeFZi
>>> 0804b8d8 T _D4test9testClassFiZC4test4Test
>>> 
>>> The whole nm output is too long, but if you want I can send it to you.
>>> 
>>> When I use the *--undefined-only* option I get: $ nm -u prog
>>> [snip]
>> 
>> All unresolved symbols seem to be in glibc.
>> 
> Yes.
> 
>> I've filed a bug:
>> http://d.puremagic.com/issues/show_bug.cgi?id=3226
> 
> I don't have the warning you mention.

Try to run

objdump -r test.o

It'll print relocation table for the object file.  In my case almost all
of them are of type R_386_32 which are load-time relocations.  A
position-independent code should not contain them.