object.d: Error: module object is in file 'object.d' which cannot be read

[Jonathan M Davis]

On 2011-03-27 13:20, Jacob Carlborg wrote:
> On 2011-03-27 21:24, Ishan Thilina wrote:
> > @Jacob:
> > 
> > An error comes when the " ./dvm install dvm" command is given.
> > 
> > "
> > ./dvm: error while loading shared libraries: libz.so.1: cannot open
> > shared object file: No such file or directory
> 
> You don't have libz installed? Oh, you're running 64bit, you need to
> install 32bit libraries. I also forgot to mention that DVM currently
> only installs the 32bit version of DMD. The 64bit version is quite new,
> don't know if it's experimental, alpha or beta.

Probably alpha. I believe that it mostly works, but there are still plenty of 
bugs to find, I'm sure.

However, depending on what you mean by "installing" the compiler, there is no 
32-bit vs 64-bit version. Only the libraries differ. There is only a 32-bit 
binary for the compiler, and you pass it -m64 if you want it to compile 64-bit 
binaries. So, if your tool deals with the compiler only, then 32-bit vs 64-bit 
is currently a moot point. On the other hand, if it deals with the standard 
libraries too (as it probably does), then 32-bit vs 64-bit _is_ an issue, but 
it isn't an issue for the compiler itself. And unless you're not using the 
standard dmd.conf as part of switching compilers, there would already be a 
difference in the library layout once 64-bit compilation was introduced, since 
the 32-bit Phobos was moved from dmd2/linux/lib to dmd2/linux/lib32 (with the 
64-bit version in dmd2/linux/lib64). And if you made the lib32 change, then 
having it work with 64-bit is likely trivial. And if you didn't make such a 
change, you're going to have to eventually. Personally, I don't see tha alpha 
quality of the 64-bit code generation to be a reason not to support it. It's 
been released. But then again, I don't use your tool at all and find no need 
for it, so it's not like I'm one of your users.

- Jonathan M Davis