On 18.05.2013 00:49, Dmitry Olshansky wrote:
17-May-2013 21:57, Rainer Schuetze пишет:
On 17.05.2013 14:29, Dmitry Olshansky wrote:
15-May-2013 04:17, IgorStepanov пишет:
Do this table linked, if you remove all functions, which use it?
Thanks for this try, but they DO link in always.
And I believe this is a key problem - each function goes into a separate
object but globals are always pulled in!
Yes, if you build a library the functions in a module are split into
separate object files, but data is always written into the object file
of the original module. The linker cannot split these afterwards if any
data in the module is referenced (which might happen by just importing
the module).
And how then I would use these tables if even importing these modules
then pulls in the data?
It depends. An imported module is referenced if it is part of the
dependency chain for static constructors, i.e if it contains static
this() or imports something that contains it. A module with just data in
it should be fine.
Local import doesn't help too.
A workaround could be to put the data into a different module.
Then say I go for X files with tables and import these modules.
It still doesn't work - evidently simply referencing a module pulls in
the data.
If I compile and link the following 3 modules:
module fmod;
public immutable int[] fable = [1,2,3];
module mod;
import fmod;
int foo(int i)
{
return fable[i];
}
//driver
import mod;
immutable byte[] bable = [1, 2, 3, 4, 5];
byte boo(int ch){
return bable[ch];
}
void main(string[] args){
boo(0);
}
I still have this symbol in map file: _D4fmod5fableyAi
That is immutable(int[]) fmod.fable after ddemangle.
If you compile all the files on the command line for the executable
everything gets dragged in. You will have to build the first two modules
into a library:
dmd -lib fmod.d mod.d -ofm.lib
dmd -map driver.d m.lib
grep fmod driver.map
Splitting functions into separate object files also only happens when
-lib is specified.
