Thread overview
Building DMD
Mar 31, 2017
Inquie
Mar 31, 2017
Nicholas Wilson
Mar 31, 2017
Inquie
Mar 31, 2017
Stefan Koch
Mar 31, 2017
Inquie
Apr 01, 2017
Inquie
Apr 01, 2017
Inquie
March 31, 2017
I am trying to build DMD 64-bit. I was able to build everything after getting the paths fixed for zlib, druntime, and phobos. Everything seems to compile. I replaced all the files generated in to the dmd directories of the old ones. (phobos64.lib, gcstub.obj, dmd.exe)

But anytime I build my projects that worked fine in the x86 compiler I get the errors:

 Error 42: Symbol Undefined __d_arrayboundsp
 Error 42: Symbol Undefined __d_assertp

These seem like dmd runtime functions or something similar but not sure why they don't exist.

Any ideas? Are these functions suppose to be in phobos or druntime? and why aren't they showing up when I build from sources and replaced everything, I believe, correctly?
March 31, 2017
On Friday, 31 March 2017 at 07:23:42 UTC, Inquie wrote:
> I am trying to build DMD 64-bit. I was able to build everything after getting the paths fixed for zlib, druntime, and phobos. Everything seems to compile. I replaced all the files generated in to the dmd directories of the old ones. (phobos64.lib, gcstub.obj, dmd.exe)
>
> But anytime I build my projects that worked fine in the x86 compiler I get the errors:
>
>  Error 42: Symbol Undefined __d_arrayboundsp
>  Error 42: Symbol Undefined __d_assertp
>
> These seem like dmd runtime functions or something similar but not sure why they don't exist.
>
> Any ideas? Are these functions suppose to be in phobos or druntime? and why aren't they showing up when I build from sources and replaced everything, I believe, correctly?

Those are runtime functions. Did you build druntime64.lib? If so is it up to date? The compiler and runtime are required to by in sync.

Alternately compiling with `-release -boundscheck=off` should remove reliance on those functions (this is not a proper solution).
March 31, 2017
On Friday, 31 March 2017 at 08:20:51 UTC, Nicholas Wilson wrote:
> On Friday, 31 March 2017 at 07:23:42 UTC, Inquie wrote:
>> I am trying to build DMD 64-bit. I was able to build everything after getting the paths fixed for zlib, druntime, and phobos. Everything seems to compile. I replaced all the files generated in to the dmd directories of the old ones. (phobos64.lib, gcstub.obj, dmd.exe)
>>
>> But anytime I build my projects that worked fine in the x86 compiler I get the errors:
>>
>>  Error 42: Symbol Undefined __d_arrayboundsp
>>  Error 42: Symbol Undefined __d_assertp
>>
>> These seem like dmd runtime functions or something similar but not sure why they don't exist.
>>
>> Any ideas? Are these functions suppose to be in phobos or druntime? and why aren't they showing up when I build from sources and replaced everything, I believe, correctly?
>
> Those are runtime functions. Did you build druntime64.lib? If so is it up to date? The compiler and runtime are required to by in sync.
>
> Alternately compiling with `-release -boundscheck=off` should remove reliance on those functions (this is not a proper solution).

Yes, I downloaded druntime from github and built it as I did phobos. The 64-bit make files have issues because paths are hard coded and things are not so simple as they used to be, but I was able to, I think, get everything to work.

So, if this is a druntime issue, and if built it "correctly" is there any settings I would have to change to add them or anything like that? Any way to check if those symbols exist in druntime64.lib?

It seems the methods are in

src\core\exception.d

so not sure why they wouldn't be added.


But yes, I downloaded everything nearly simultaneously and build them.
March 31, 2017
On Friday, 31 March 2017 at 14:19:59 UTC, Inquie wrote:
> On Friday, 31 March 2017 at 08:20:51 UTC, Nicholas Wilson wrote:
>> [...]
>
> Yes, I downloaded druntime from github and built it as I did phobos. The 64-bit make files have issues because paths are hard coded and things are not so simple as they used to be, but I was able to, I think, get everything to work.
>
> So, if this is a druntime issue, and if built it "correctly" is there any settings I would have to change to add them or anything like that? Any way to check if those symbols exist in druntime64.lib?
>
> It seems the methods are in
>
> src\core\exception.d
>
> so not sure why they wouldn't be added.
>
>
> But yes, I downloaded everything nearly simultaneously and build them.

Download the source of a release version.
~master is always a little unstable.
picking the ~stable branch for phobos druntime and dmd should end up in a working compiler close to the latest release.
March 31, 2017
On Friday, 31 March 2017 at 14:24:43 UTC, Stefan Koch wrote:
> On Friday, 31 March 2017 at 14:19:59 UTC, Inquie wrote:
>> On Friday, 31 March 2017 at 08:20:51 UTC, Nicholas Wilson wrote:
>>> [...]
>>
>> Yes, I downloaded druntime from github and built it as I did phobos. The 64-bit make files have issues because paths are hard coded and things are not so simple as they used to be, but I was able to, I think, get everything to work.
>>
>> So, if this is a druntime issue, and if built it "correctly" is there any settings I would have to change to add them or anything like that? Any way to check if those symbols exist in druntime64.lib?
>>
>> It seems the methods are in
>>
>> src\core\exception.d
>>
>> so not sure why they wouldn't be added.
>>
>>
>> But yes, I downloaded everything nearly simultaneously and build them.
>
> Download the source of a release version.
> ~master is always a little unstable.
> picking the ~stable branch for phobos druntime and dmd should end up in a working compiler close to the latest release.


So, I downloaded all stables an rebuilt and replaced and same error ;/(dmd, druntime, and phobos)

The error seems to be in something else:

1. I had to use fix up the paths to get win64.mak to compile because the paths are hard coded for old visual studio/clang/sdk's that simply do not translate in to the newer visual studio revamps. (wish it did, because it's a pain to find all the right files).

2. druntime64.lib has _d_arrayboundsp and _d_assertp in it(doing a text search).

Any ideas? I'm at a loss. So close but so far!


April 01, 2017
So, I rebuilt everything again from scratch, I fixed up the make files and such and everything went smooth. I was able to not have the errors.

I think what I did first was I built dmdx64 then copied it to the bin dir and tried to use it but got the phobos errors. I then tried to build druntime/phobos and it was trying to use that version of the dmd, which I guess was faulty because phobos\druntime wasn't correct. Instead, I simply built everything first then copied everything together and that seemed to work.

It would be real nice if we could have the x64 version added to the distro so people don't have to rebuild each time. Also, the make files needs to be updated to support the latest VS. It's nice that the build process went pretty smooth otherwise though.

Seems to work but now I run in to two problems:

If I try to compile for win32 I get

Error: more than 32767 symbols in object file

if I try to compile for x64 I get

fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '_D6modu2557__T19fooVAyaa13_6d50686f746f73686f70434f4dVAAyaA82a11_4170706c69636174696f6ea8_446f63756d656e74a8_4172744c61796572a8_546578744974656da10_536f6c6964436f6c6f72a8_524742436f6c6f72a9_47726179436f6c6f72a9_434d594b436f6c6f72a8_4c6162436f6c6f72a8_485342436f6c6f72a8_4c61796572536574a6_4c6179657273a9_4c6179657253657473a9_4172744c6179657273a12_486973746f72795374617465a12_446f63756d656e74496e666fa9_53656c656374696f6ea7_4368616e6e656ca11_584d504d65746164617461a16_4d6561737572656d656e745363616c65a8_4368616e6e656c73a13_486973746f7279537461746573a10_4c61796572436f6d7073a9_4c61796572436f6d70a9_506174684974656d73a8_506174684974656da12_537562506174684974656d73a11_537562506174684974656da10_50617468506f696e7473a9_50617468506f696e74a10_436f756e744974656d73a9_436f756e744974656da13_436f6c6f7253616d706c657273a12_436f6c6f7253616d706c6572a11_507265666572656e636573a9_446f63756d656e7473a9_54657874466f6e7473a8_54657874466f6e74a9_4e6f74696669657273a8_4e6f746966696572a14_4d6561737572656d656e744c6f67a16_416374696f6e44657363726970746f72a10_416374696f6e4c697374a15_416374696f6e5265666572656e6365a18_50686f746f43444f70656e4f7074696f6e73a20_526177466f726d61744f70656e4f7074696f6e73a14_5044464f70656e4f7074696f6e73a14_4550534f70656e4f7074696f6e73a16_4449434f4d4f70656e4f7074696f6e73a20_43616d6572615241574f70656e4f7074696f6e73a20_50686f746f73686f70536176654f7074696f6e73a14_424d50536176654f7074696f6e73a14_474946536176654f7074696f6e73a14_455053536176654f7074696f6e73a15_4a504547536176654f7074696f6e73a14_504446536176654f7074696f6e73a19_5049435446696c65536176654f7074696f6e73a16_5069786172536176654f7074696f6e73a14_504e47536176654f7074696f6e73a14_526177536176654f7074696f6e73a17_534749524742536176654f7074696f6e73a16_5461726761536176654f7074696f6e73a15_54696666536176654f7074696f6e73a16_444353315f536176654f7074696f6e73a16_444353325f536176654f7074696f6e73a24_4578706f72744f7074696f6e73496c6c7573747261746f72a23_4578706f72744f7074696f6e7353617665466f72576562a23_4269746d6170436f6e76657273696f6e4f7074696f6e73a24_496e6465786564436f6e76657273696f6e4f7074696f6e73a7_4e6f436f6c6f72a19_50726573656e746174696f6e4f7074696f6e73a14_47616c6c6572794f7074696f6e73a20_47616c6c65727942616e6e65724f7074696f6e73a20_47616c6c657279496d616765734f7074696f6e73a23_47616c6c6572795468756d626e61696c4f7074696f6e73a25_47616c6c657279437573746f6d436f6c6f724f7074696f6e73a22_47616c6c65727953656375726974794f7074696f6e73a19_436f6e7461637453686565744f7074696f6e73a21_506963747572655061636b6167654f7074696f6e73a12_42617463684f7074696f6e73a11_53756250617468496e666fa13_50617468506f696e74496e666fZ19.....

It seems I get the corrupt comdat when using come ctfe stuff.
April 01, 2017
On Saturday, 1 April 2017 at 00:12:10 UTC, Inquie wrote:
> So, I rebuilt everything again from scratch, I fixed up the make files and such and everything went smooth. I was able to not have the errors.
>
> [...]


I was able to solve the comdat problem by moving a local function outside a loop(didn't really need to define it in the loop)... but it had no problems on previous build. Seems that the function was being defined several times due to ctfe or whatever and that caused problems.