www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Building LDC for the first time

reply "Daniel N" <ufo orbiting.us> writes:
Dear All,

I downloaded ldc-0.14.0-src.tar.gz and tried following the 
instructions located at:
http://wiki.dlang.org/Building_LDC_on_MinGW_x86

I was only partially successful.

$ uname
MINGW32_NT-6.1

My version:
LDC - the LLVM D compiler (0.14.0):
   based on DMD v2.065 and LLVM 3.5.0svn
   Default target: i686-pc-windows-gnu

Official version:
LDC - the LLVM D compiler (0.14.0):
   based on DMD v2.065 and LLVM 3.4.2
   Default target: i686-pc-mingw32

I realize I used too new LLVM, but nevertheless there's two 
things puzzling me:

1) My targetTriple.getOS() == llvm::Triple::Win32 which results 
in my compiler invoking the Visual Studio Linker, which isn't 
necessarily a bad thing, but it was unexpected, because the 
official build uses ld from MinGW.

2) The compiler builds fine, but the Druntime/Phobos doesn't.
"ldc/import\core\stdc\math.d(672): Error: undefined identifier 
isnan, did you mean function nan?" I guess that's a consequence 
of my compiler having an identity crisis, using the wrong version 
code-path...

The combination of these two issues, is a problem since the 
official build uses a different toolchain so I cannot use the 
libs from it together with the MS linker, which means I'm stuck.

I also tried using VS Express 2013:
http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC

But I can't get it to build either... my stdlib.h already defines:
long double strtold(const char *p,char **endp);
(even if long double is just 8 bytes)

But the workaround in \dmd2\root\longdouble.h redefines it as:
longdouble strtold(const char *p,char **endp);

I didn't find a clean way to solve it, every workaround resulted 
in a new error down the road until I gave up and switched to 
using MinGW...

Any advice for me? (I can't switch OS right now).
Aug 21 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
Hi Daniel!

On Friday, 22 August 2014 at 02:24:10 UTC, Daniel N wrote:

 Dear All,

 I downloaded ldc-0.14.0-src.tar.gz and tried following the 
 instructions located at:
 http://wiki.dlang.org/Building_LDC_on_MinGW_x86


Thanks for trying LDC!


 I was only partially successful.

 $ uname
 MINGW32_NT-6.1

 My version:
 LDC - the LLVM D compiler (0.14.0):
   based on DMD v2.065 and LLVM 3.5.0svn
   Default target: i686-pc-windows-gnu

 Official version:
 LDC - the LLVM D compiler (0.14.0):
   based on DMD v2.065 and LLVM 3.4.2
   Default target: i686-pc-mingw32

 I realize I used too new LLVM, but nevertheless there's two 
 things puzzling me:


In general, LLVM 3.5 should work, too. But I did not check on 
MingW.


 1) My targetTriple.getOS() == llvm::Triple::Win32 which results 
 in my compiler invoking the Visual Studio Linker, which isn't 
 necessarily a bad thing, but it was unexpected, because the 
 official build uses ld from MinGW.


If you look at the default target triple, you notice the change 
from mingw32 to windows-gnu. I think I missed to change the 
linker invocation, too. I'll check this.


 2) The compiler builds fine, but the Druntime/Phobos doesn't.
 "ldc/import\core\stdc\math.d(672): Error: undefined identifier 
 isnan, did you mean function nan?" I guess that's a consequence 
 of my compiler having an identity crisis, using the wrong 
 version code-path...


I'll check this, too. Sounds like a bug.


 The combination of these two issues, is a problem since the 
 official build uses a different toolchain so I cannot use the 
 libs from it together with the MS linker, which means I'm stuck.

 I also tried using VS Express 2013:
 http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC

 But I can't get it to build either... my stdlib.h already 
 defines:
 long double strtold(const char *p,char **endp);
 (even if long double is just 8 bytes)

 But the workaround in \dmd2\root\longdouble.h redefines it as:
 longdouble strtold(const char *p,char **endp);

 I didn't find a clean way to solve it, every workaround 
 resulted in a new error down the road until I gave up and 
 switched to using MinGW...

 Any advice for me? (I can't switch OS right now).


I am still using VisualStudio 2012. But I try to fix this, too.

I'll give you a hint when I fixes the mingw problems. Then you 
can use master branch from GitHub instead of the source 
distribution.

Regards,
Kai
Aug 21 2014
parent reply "Daniel N" <ufo orbiting.us> writes:
On Friday, 22 August 2014 at 06:13:07 UTC, Kai Nacke wrote:

 I am still using VisualStudio 2012. But I try to fix this, too.

 I'll give you a hint when I fixes the mingw problems. Then you 
 can use master branch from GitHub instead of the source 
 distribution.

 Regards,
 Kai


Hi Kai,

Awesome, thanks for confirming the bugs!

Best Regards,
Daniel N
Aug 24 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Sunday, 24 August 2014 at 16:08:02 UTC, Daniel N wrote:

 On Friday, 22 August 2014 at 06:13:07 UTC, Kai Nacke wrote:

 I am still using VisualStudio 2012. But I try to fix this, too.

 I'll give you a hint when I fixes the mingw problems. Then you 
 can use master branch from GitHub instead of the source 
 distribution.

 Regards,
 Kai


 Hi Kai,

 Awesome, thanks for confirming the bugs!

 Best Regards,
 Daniel N


Hi Daniel!

The linker issue is fixed now in master branch.

Regards,
Kai
Aug 24 2014
parent reply "Daniel N" <ufo orbiting.us> writes:
On Sunday, 24 August 2014 at 17:24:22 UTC, Kai Nacke wrote:

 Hi Daniel!

 The linker issue is fixed now in master branch.

 Regards,
 Kai


Hi Kai,

verified, now it behaves as expected. :)

Thanks for the super fast support!
Daniel N
Aug 25 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Monday, 25 August 2014 at 14:45:49 UTC, Daniel N wrote:

 On Sunday, 24 August 2014 at 17:24:22 UTC, Kai Nacke wrote:

 Hi Daniel!

 The linker issue is fixed now in master branch.

 Regards,
 Kai


 Hi Kai,

 verified, now it behaves as expected. :)

 Thanks for the super fast support!
 Daniel N


Hi Daniel,

I could not verify the second issue - but I only tried after 
fixing the linker issue. I have to use VS 2013 soon as LLVM 
project discusses to raise the minimum VS version to 2013 for 
version 3.6

Regards,
Kai
Aug 25 2014
parent reply "Daniel N" <ufo orbiting.us> writes:
On Monday, 25 August 2014 at 16:26:33 UTC, Kai Nacke wrote:

 Hi Daniel,

 I could not verify the second issue - but I only tried after 
 fixing the linker issue. I have to use VS 2013 soon as LLVM 
 project discusses to raise the minimum VS version to 2013 for 
 version 3.6

 Regards,
 Kai


Dear Kai,

I made some progress in identifying the Runtime build issue.

Basically version(LDC) && version(Win32) is true, but 
version(MinGW) isn't.

I tried a workaround, but MinGW is reserved I was not allowed to 
set it.
version( LDC )
{
//  version( Win32 )
//      version = MinGW;
     version( Win64 )
         version = MSVC_RUNTIME;
}

If I hack the file, so that the MinGW codepath is taken, then it 
compiles perfectly(until I hit the same issue in another file).

I haven't backtracked how 'version' is implemented yet, I guess 
the issue could originate all the way from cmake?

Best Regards,
Daniel N

PS Is there a switch to print the built-in versions? I couldn't 
find it.
Aug 26 2014
next sibling parent reply "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 26 August 2014 at 08:06:40 UTC, Daniel N wrote:

 On Monday, 25 August 2014 at 16:26:33 UTC, Kai Nacke wrote:

 Hi Daniel,

 I could not verify the second issue - but I only tried after 
 fixing the linker issue. I have to use VS 2013 soon as LLVM 
 project discusses to raise the minimum VS version to 2013 for 
 version 3.6

 Regards,
 Kai




PS I found the bug:
\ldc_master\driver\main.cpp

OLD Code:
#if LDC_LLVM_VER >= 306
             if 
(global.params.targetTriple.isWindowsGNUEnvironment())
             {
                 
VersionCondition::addPredefinedGlobalIdent("mingw32"); // For 
backwards compatibility.
                 
VersionCondition::addPredefinedGlobalIdent("MinGW");
             }
Working Code:
#if LDC_LLVM_VER >= 305

Best Regards,
Daniel N
Aug 26 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Tuesday, 26 August 2014 at 08:36:26 UTC, Daniel N wrote:

 On Tuesday, 26 August 2014 at 08:06:40 UTC, Daniel N wrote:

 On Monday, 25 August 2014 at 16:26:33 UTC, Kai Nacke wrote:

 Hi Daniel,

 I could not verify the second issue - but I only tried after 
 fixing the linker issue. I have to use VS 2013 soon as LLVM 
 project discusses to raise the minimum VS version to 2013 for 
 version 3.6

 Regards,
 Kai




 PS I found the bug:
 \ldc_master\driver\main.cpp

 OLD Code:
 #if LDC_LLVM_VER >= 306
             if 
 (global.params.targetTriple.isWindowsGNUEnvironment())
             {
                 
 VersionCondition::addPredefinedGlobalIdent("mingw32"); // For 
 backwards compatibility.
                 
 VersionCondition::addPredefinedGlobalIdent("MinGW");
             }
 Working Code:
 #if LDC_LLVM_VER >= 305

 Best Regards,
 Daniel N


Thanks for debugging! I commit this asap.

Regards,
Kai
Aug 26 2014
parent reply "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 26 August 2014 at 10:57:51 UTC, Kai Nacke wrote:

 Thanks for debugging! I commit this asap.

 Regards,
 Kai


Awesome, No problem!

You probably realized already, but just to make sure, grepping 
after isWindowsGNUEnvironment revealed more of the same:
./driver/linker.cpp
./driver/main.cpp
./driver/toobj.cpp
./gen/declarations.cpp
./gen/naked.cpp:

Regards,
Daniel N
Aug 26 2014
parent reply "Kai Nacke" <kai redstar.de> writes:
On Tuesday, 26 August 2014 at 12:08:53 UTC, Daniel N wrote:

 On Tuesday, 26 August 2014 at 10:57:51 UTC, Kai Nacke wrote:

 Thanks for debugging! I commit this asap.

 Regards,
 Kai


 Awesome, No problem!

 You probably realized already, but just to make sure, grepping 
 after isWindowsGNUEnvironment revealed more of the same:
 ./driver/linker.cpp
 ./driver/main.cpp
 ./driver/toobj.cpp
 ./gen/declarations.cpp
 ./gen/naked.cpp:

 Regards,
 Daniel N


Thanks for the hint. I committed the change. If you like you can 
try it...

Regards,
Kai
Aug 26 2014
parent reply "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 26 August 2014 at 17:00:37 UTC, Kai Nacke wrote:

 Thanks for the hint. I committed the change. If you like you 
 can try it...

 Regards,
 Kai


Thanks, the patch works like a Charm! It allowed me to find the 
next(and probably final issue).

When building with LLVM 3.5 my GCC/GAS is not happy with certain 
COMDAT directives, I tested switching to build with my own 
compiled LLVM 3.4.2 that is fully functional as expected.

If I use "-disable-linker-strip-dead" then the 'one_only' syntax 
returns to the old 3.4.2 style, but the new 'discard' syntax 
remain despite the switch, see below comparison for what I mean.

=== 34 ===
.text
.linkonce discard

=== 35 ===
.section	.text,"xr",one_only,__Dmain
.section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

=== 35 && -disable-linker-strip-dead ===
.text
.section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

Regards,
Daniel N
Aug 27 2014
next sibling parent "Daniel N" <ufo orbiting.us> writes:
On Wednesday, 27 August 2014 at 14:59:33 UTC, Daniel N wrote:

 === 35 && -disable-linker-strip-dead ===
 .text
 .section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi


PS I found a fix so that I don't have to specify 
-disable-linker-strip-dead

.\driver\targetmachine.cpp

= Before =
if (!noLinkerStripDead && (triple.getOS() == llvm::Triple::Linux 
|| triple.getOS() == llvm::Triple::Win32))

But for "LDC_LLVM_VER >= 305" I guess you need to use
"triple.isWindowsMSVCEnvironment()" instead of "triple.getOS() == 
llvm::Triple::Win32".

I didn't find a fix for the 2nd issue yet though.

Regards,
Daniel N
Aug 27 2014
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 27 August 2014 at 14:59:33 UTC, Daniel N wrote:

 On Tuesday, 26 August 2014 at 17:00:37 UTC, Kai Nacke wrote:

 Thanks for the hint. I committed the change. If you like you 
 can try it...

 Regards,
 Kai


 Thanks, the patch works like a Charm! It allowed me to find the 
 next(and probably final issue).

 When building with LLVM 3.5 my GCC/GAS is not happy with 
 certain COMDAT directives, I tested switching to build with my 
 own compiled LLVM 3.4.2 that is fully functional as expected.

 If I use "-disable-linker-strip-dead" then the 'one_only' 
 syntax returns to the old 3.4.2 style, but the new 'discard' 
 syntax remain despite the switch, see below comparison for what 
 I mean.

 === 34 ===
 .text
 .linkonce discard

 === 35 ===
 .section	.text,"xr",one_only,__Dmain
 .section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

 === 35 && -disable-linker-strip-dead ===
 .text
 .section	.text,"xr",discard,__D4dial13__T6createTiZ6createFNaNbNfiZi

 Regards,
 Daniel N


Hi Daniel!

You could try the integrated LLVM assembler. I am currently 
testing this setup.

1. In driver/toobj.cpp, set bool const assembleExternally = false;
2. in std.math, exchange in real poly(...) the inline assembler 
with the D version (simply replace D_InlineAsm_X86 with none).

This is what I am currently testing.

Regards,
Kai
Aug 27 2014
next sibling parent "Daniel N" <ufo orbiting.us> writes:
On Wednesday, 27 August 2014 at 17:14:24 UTC, Kai Nacke wrote:

 Hi Daniel!

 You could try the integrated LLVM assembler. I am currently 
 testing this setup.

 1. In driver/toobj.cpp, set bool const assembleExternally = 
 false;
 2. in std.math, exchange in real poly(...) the inline assembler 
 with the D version (simply replace D_InlineAsm_X86 with none).

 This is what I am currently testing.

 Regards,
 Kai


Hi Kai,

yay, it works! Thanks for the fantastic support.

Regards,
Daniel N
Aug 27 2014
prev sibling next sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 2 Sep 2014, at 2:09, David Nadlinger wrote:

 SEH support to the MC assembler […]

 SEH […]


Whoops, I of course meant to write DW(arf) 2 EH, not SEH.
Sep 01 2014
next sibling parent "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 2 September 2014 at 00:22:52 UTC, David Nadlinger via 
digitalmars-d-ldc wrote:

 On 2 Sep 2014, at 2:09, David Nadlinger wrote:

 SEH support to the MC assembler […]

 SEH […]


 Whoops, I of course meant to write DW(arf) 2 EH, not SEH.


Hi David,

it seems OK to me(disclaimer: I don't speak fluent dwarf).

objdump.exe dial.exe --dwarf=frames-interp

dial.exe:     file format pei-i386

Contents of the .eh_frame section:

00000000 00000014 00000000 CIE "zR" cf=1 df=-4 ra=8
    LOC   CFA      ra
00000000 esp+4    c-4

00000018 00000010 0000001c FDE cie=00000000 pc=ffebb000..ffebb002
    LOC   CFA      ra
ffebb000 esp+4    c-4

0000002c 00000020 00000030 FDE cie=00000000 pc=ffebb010..ffebb12e
    LOC   CFA      ra
ffebb010 esp+4    c-4
ffebb013 esp+32   c-4
ffebb098 esp+4    c-4
ffebb0a0 esp+4    c-4
ffebb111 esp+4    c-4
ffebb112 esp+4    c-4
Sep 01 2014
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Tuesday, 2 September 2014 at 00:22:52 UTC, David Nadlinger via 
digitalmars-d-ldc wrote:

 On 2 Sep 2014, at 2:09, David Nadlinger wrote:

 SEH support to the MC assembler […]

 SEH […]


 Whoops, I of course meant to write DW(arf) 2 EH, not SEH.


Hi David,

before posting I checked that I could debug a simple application. 
Seems to work now.

Regards,
Kai
Sep 01 2014
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 2 Sep 2014, at 7:30, Kai Nacke via digitalmars-d-ldc wrote:

 before posting I checked that I could debug a simple application. 
 Seems to work now.


The question is whether exception handling works at all when using the 
MC asm. Previously, the tables necessary for EH were not correctly 
emitted.

Best,
David
Sep 02 2014
parent reply "Daniel N" <ufo orbiting.us> writes:
On Wednesday, 3 September 2014 at 01:12:17 UTC, David Nadlinger 
via digitalmars-d-ldc wrote:

 On 2 Sep 2014, at 7:30, Kai Nacke via digitalmars-d-ldc wrote:

 before posting I checked that I could debug a simple 
 application. Seems to work now.


 The question is whether exception handling works at all when 
 using the MC asm. Previously, the tables necessary for EH were 
 not correctly emitted.

 Best,
 David


13/476  Testing: core.exception:
24/476  Testing: core.sync.exception
157/476 Testing: std.exception
245/476 Testing: core.exception-debug
256/476 Testing: core.sync.exception-debug
389/476 Testing: std.exception-debug
======

All of the above return: Test Passed.

My own application which uses exceptions seem fine to.

Regards,
Daniel N
Sep 02 2014
parent "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 3 September 2014 at 06:27:49 UTC, Daniel N wrote:

 On Wednesday, 3 September 2014 at 01:12:17 UTC, David Nadlinger 
 via digitalmars-d-ldc wrote:

 On 2 Sep 2014, at 7:30, Kai Nacke via digitalmars-d-ldc wrote:

 before posting I checked that I could debug a simple 
 application. Seems to work now.


 The question is whether exception handling works at all when 
 using the MC asm. Previously, the tables necessary for EH were 
 not correctly emitted.

 Best,
 David


 13/476  Testing: core.exception:
 24/476  Testing: core.sync.exception
 157/476 Testing: std.exception
 245/476 Testing: core.exception-debug
 256/476 Testing: core.sync.exception-debug
 389/476 Testing: std.exception-debug
 ======

 All of the above return: Test Passed.

 My own application which uses exceptions seem fine to.

 Regards,
 Daniel N


Thanks for checking!

Regards,
Kai
Sep 03 2014
prev sibling parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
On 27 Aug 2014, at 19:14, Kai Nacke via digitalmars-d-ldc wrote:

 You could try the integrated LLVM assembler. I am currently testing 
 this setup.

 1. In driver/toobj.cpp, set bool const assembleExternally = false;
 2. in std.math, exchange in real poly(...) the inline assembler with 
 the D version (simply replace D_InlineAsm_X86 with none).

 This is what I am currently testing.


Have the LLVM folks added SEH support to the MC assembler recently? 
Otherwise, this will not work.

SEH is the sole reason for which I switched the MinGW port to using GAS. 
The sooner we can get rid of it, the better.

Best,
David
Sep 01 2014
parent "Kai Nacke" <kai redstar.de> writes:
On Tuesday, 2 September 2014 at 00:38:08 UTC, David Nadlinger via 
digitalmars-d-ldc wrote:

 On 27 Aug 2014, at 19:14, Kai Nacke via digitalmars-d-ldc wrote:

 You could try the integrated LLVM assembler. I am currently 
 testing this setup.

 1. In driver/toobj.cpp, set bool const assembleExternally = 
 false;
 2. in std.math, exchange in real poly(...) the inline 
 assembler with the D version (simply replace D_InlineAsm_X86 
 with none).

 This is what I am currently testing.


 Have the LLVM folks added SEH support to the MC assembler 
 recently? Otherwise, this will not work.

 SEH is the sole reason for which I switched the MinGW port to 
 using GAS. The sooner we can get rid of it, the better.

 Best,
 David


BTW: With SEH support added we can try to create a MinGW64 
build...

Regards,
Kai
Sep 01 2014
prev sibling parent reply "Joakim" <dlang joakim.airpost.net> writes:
On Tuesday, 26 August 2014 at 08:06:40 UTC, Daniel N wrote:

 PS Is there a switch to print the built-in versions? I couldn't 
 find it.


If you just want a list of all of them, it's in dmd2/cond.c:

https://github.com/ldc-developers/ldc/blob/master/dmd2/cond.c#L153

If you want to know what's currently enabled for any particular 
invocation of the compiler, add the -v flag and it'll show them 
at the top.
Aug 26 2014
parent "Daniel N" <ufo orbiting.us> writes:
On Tuesday, 26 August 2014 at 12:07:59 UTC, Joakim wrote:

 If you want to know what's currently enabled for any particular 
 invocation of the compiler, add the -v flag and it'll show them 
 at the top.


Super, that was exactly what I was looking for. :)

Thanks!
Daniel N
Aug 27 2014