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

[Jacob Carlborg]

On 2011-03-27 23:05, Jonathan M Davis wrote:
> 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

What I meant with "installing" is that he shouldn't expect to be able to 
produce 64bit binaries with a DMD installed with my tool.

I have changed the tool to handle the lib -> lib32/lib64 change. It is a 
trivial change to make the 64bit installation possible. The reason I 
have made that change yet is a couple of reasons:

* I was planning to refactor the whole tool into a library and a tool 
using that library. I was planning to wait with all the new 
functionality until after the refactoring was done.

* I'm not 100% how I want the default behavior to be. When the 64bit is 
mature enough that will probably be the default when running on a 64bit 
machine and otherwise 32bit. I will also provide an option to installed 
the non-native library as well. The question is, what should be the 
default behavior now on a 64bit machine, 32bit or 64bit?

Yes, I do have a custom dmd.conf. No reason to put the "bin" folder in 
an extra folder just because that's the layout in the zip file.

I guess you're right, that I shouldn't blame the current status of the 
64bit code generation as a reason not to support installing it. Just 
thought it was easier to explain it that way the more complete 
explanation I gave here.

I do know that the compiler can produce both 32 and 64bit binaries and 
the only difference is the standard library.

-- 
/Jacob Carlborg