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.
