Shared Object with DMD v2.031

[teo]

On Thu, 06 Aug 2009 04:24:35 +0400, Sergey Gromov wrote:

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

Correct. This is exactly the case. And my environment is identical to 
yours:
$ dmd | head -n1
Digital Mars D Compiler v2.031
$ gcc --version | head -n1
gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
$ uname -a
Linux dev-phobos 2.6.28-14-server #47-Ubuntu SMP Sat Jul 25 01:18:34 UTC 
2009 i686 GNU/Linux

So it is reproducible with DMD2 as well.