Can dmd compile with my own runtime library?

[Frits van Bommel]

Huang F Guan wrote:
> Frits van Bommel Wrote:
[SNIP]
> 
> Thank you for your ideas, it's nice of you!
> 
> I did what you told, but I failed again.
> When I tried to make a simple phonbos library( I removed a lot of code ), I got lots of errors.
> 
> 1. I wrote a simple object.d, it only contains a Object class and a ClassInfo class. But DMD compiled failed.
> dmd -c object.d
> object.d(6): class object.Object D compiler and phobos/object.d are mismatched
> object.d(29): class object.ClassInfo D compiler and phobos/object.d are mismatched

The compilers depend on some things in object.d being exactly as they 
are in the version supplied with the compiler.
The ones I'm aware of:
1) The TypeInfo* classes must be present (and you probably shouldn't 
change their data members either).
2) The same goes for ClassInfo (and possibly the Interface and 
OffsetTypeInfo structs it uses, but I'm not sure). I'm sure you 
shouldn't change the data members (Or at least their total size; but 
it's probably best to keep their types and order intact as well or 
they'll likely be useless). In fact, changes in data members probably 
caused your second error message.
3) class Object must obviously be present. It may be a bad idea to add 
data members, which might have caused that first error message.

In all of the above cases you can probably safely change the methods 
though. I don't see why you would in the case of TypeInfo*, but you can 
probably remove ClassInfo.{find,create}. Changing Object methods is 
probably the most useful form of this (in fact, the one in Tango has 
some changes; it removes Object.print and renames toString to toUtf8).
The implementations of TypeInfo_Class and TypeInfo_Interface use some 
Object members though (toHash, opEquals and opCmp) so you might want to 
keep that functionality intact, at least[1].


[1] Those TypeInfo members are used by associative arrays for keys IIRC, 
so if you plan on using AAs with classes or interfaces as key types 
you'll need them to work correctly. I'm not sure if AAs depend on the GC 
though, so you may well want to avoid them if you don't plan on using GC 
without checking and/or fixing that (AA operations are implemented in 
library functions to which the compiler just inserts calls).

> 2. I used GDC to do the same thing. But GDC was even worse:
> 
> M:\dmd\1>gdc -c object.d
> Assertion failed: classinfo->structsize == CLASSINFO_SIZE, file ../../gcc-3.4.5-
> 20060117-1/gcc/d/dmd/toobj.c, line 417
[snip]

Actually, it isn't that much worse. It has the same cause as the second 
compiler error DMD gave, (2) above. DMD used to have pretty much the 
same error message, but may have changed it to the friendlier version 
you got.
Like I said, don't change the data members of object.ClassInfo.
Also, note that GDC 0.23 used a different (shorter) ClassInfo than 
recent DMD versions since it was based on an older DMD version; it will 
give that error if you try to use it with the newer definition. GDC 0.24 
came out yesterday with an updated version though, so that may not be a 
problem in this case.


In reality you don't really need to change much in object.d. Before I 
switched to Tango I had a slightly modified version that didn't change 
data members, removed some final and static functions, but only changed 
method definitions of virtual functions (mostly so they didn't depend on 
C library functions like printf that I hadn't implemented, importing 
some modules from my kernel to use in their place).
Currently I just use an unmodified object.d(i) from Tango (which isn't 
the same as the one included with the compilers)

If you do plan to create your own version of object.d, the safest path 
would probably be to copy the one that came with your compiler (or 
Tango), and only change what you need to for it to compile and link 
successfully (like use of above-mentioned C functions). Anything with 
"notify" in the name seems to be safe to remove too.

In general, the way I used to create my own runtime library was to use 
such a slightly-modified object.d, and not include anything else until 
one of the following happened:
1) I needed a function that I didn't have in my source tree, or
2) The compiler generated a reference to data[2] or a function that is 
normally defined in Phobos. (The way to tell if this is happening is to 
see if you have any link errors, by the way)

Then find what you need and include that (or a ported or rewritten 
version of it) into your source tree. To decode linker errors with _D* 
names in them you might want to compile the example code from 
std.demangle and pipe them through it. Then you can grep through the 
source of one one of the standard libraries (Phobos or Tango) to see 
what they do and how they are implemented there.



[2] TypeInfo data for simple types, Objects, or one-dimensional arrays 
of those mostly.