www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Building DMD

reply Inquie <Inquie data.com> writes:
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?
Mar 31
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
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).
Mar 31
parent reply Inquie <Inquie data.com> writes:
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.
Mar 31
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Mar 31
parent reply Inquie <Inquie data.com> writes:
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!
Mar 31
parent reply Inquie <Inquie data.com> writes:
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.
Mar 31
parent Inquie <Inquie data.com> writes:
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.
Mar 31