www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - LDC2 Status

reply dsimcha <dsimcha yahoo.com> writes:
I tried LDC2 for Linux out last week and again last night.  I didn't 
spend much time on it on either attempt, but so far I haven't been able 
to get even Hello, World to compile.  It seems like the instructions for 
building druntime, etc. are horribly outdated, the patches bit rotted, 
etc.  Has anyone managed to get past these hurdles and compile Hello, 
World lately?  If so, would you mind posting some instructions?  If LDC2 
is, in fact, mature enough that it would be worthwhile, I'd like to test 
it out, file bug reports, etc.
Feb 22 2011
next sibling parent Trass3r <un known.com> writes:
 I tried LDC2 for Linux out last week and again last night.


I was even more self-torturing, I tried to compile it on Windoze twice I think.
But it didn't really work.
Also I got the feeling that LDC2 has been hastily updated to the newest dmd
frontend without verifying each upgrade step by step and now things are subtly
broken.
Feb 23 2011
prev sibling next sibling parent reply Alexey Prokhin <alexey.prokhin yandex.ru> writes:
 LDC2 Status


LDC2 passes almost all phobos unittests and tests from dmd suite on linux x86.
Also it probably works on freebsd, but it's broken on other platforms and
architectures. 
I currently work on linux X86_64 port: ldc2 already compiles druntime and
phobos, although there are some serious issues with GC (which make ldc2 quite
useless on 64 bits).

Trass3r Wrote:

 Also I got the feeling that LDC2 has been hastily updated to the newest dmd
frontend without verifying each upgrade step by step and now things are subtly
broken.


When I started to work on ldc2, it was in terrible state (it did not even
compile). So, yes, I decided to update ldc to the latest dmd frontend at the
time. But after that every frontend merge was thoroughly tested using phobos
unittests and dmd test suite.


I need a hand with writing a good building instruction. If you want to help,
send me a letter, I'll talk you through building process.
By the way, druntime and phobos with ldc2 patches can be found here:
https://github.com/AlexeyProkhin.
Feb 23 2011
next sibling parent reply Trass3r <un known.com> writes:
 Trass3r Wrote:

 Also I got the feeling that LDC2 has been hastily updated to the newest  
 dmd frontend without verifying each upgrade step by step and now things  
 are subtly broken.


 When I started to work on ldc2, it was in terrible state (it did not  
 even compile). So, yes, I decided to update ldc to the latest dmd  
 frontend at the time. But after that every frontend merge was thoroughly  
 tested using phobos unittests and dmd test suite.


Glad to hear that! Didn't mean to talk your efforts down ;)
Hope you can make it usable. Now if only those LLVM suckers implemented  
SEH...



 I need a hand with writing a good building instruction. If you want to  
 help, send me a letter, I'll talk you through building process.
 By the way, druntime and phobos with ldc2 patches can be found here:  
 https://github.com/AlexeyProkhin.


I might try compiling it on Windows again.
Feb 23 2011
parent reply Don <nospam nospam.com> writes:
Trass3r wrote:

 Trass3r Wrote:

 Also I got the feeling that LDC2 has been hastily updated to the 
 newest dmd frontend without verifying each upgrade step by step and 
 now things are subtly broken.


 When I started to work on ldc2, it was in terrible state (it did not 
 even compile). So, yes, I decided to update ldc to the latest dmd 
 frontend at the time. But after that every frontend merge was 
 thoroughly tested using phobos unittests and dmd test suite.


 
 Glad to hear that! Didn't mean to talk your efforts down ;)
 Hope you can make it usable. Now if only those LLVM suckers implemented 
 SEH...


Wouldn't it be possible for LDC to use the exception handling 
implementation in druntime? (With some modifications, of course). With 
the last compiler release, there is no longer any dependency on the DMC 
runtime. I put a lot of effort into understanding Windows SEH, and I 
believe it is quite well documented now.



 I need a hand with writing a good building instruction. If you want to 
 help, send me a letter, I'll talk you through building process.
 By the way, druntime and phobos with ldc2 patches can be found here: 
 https://github.com/AlexeyProkhin.


 
 I might try compiling it on Windows again.
Feb 25 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-02-25 10:10, Don wrote:

 Trass3r wrote:

 Trass3r Wrote:

 Also I got the feeling that LDC2 has been hastily updated to the
 newest dmd frontend without verifying each upgrade step by step and
 now things are subtly broken.


 When I started to work on ldc2, it was in terrible state (it did not
 even compile). So, yes, I decided to update ldc to the latest dmd
 frontend at the time. But after that every frontend merge was
 thoroughly tested using phobos unittests and dmd test suite.


 Glad to hear that! Didn't mean to talk your efforts down ;)
 Hope you can make it usable. Now if only those LLVM suckers
 implemented SEH...


 Wouldn't it be possible for LDC to use the exception handling
 implementation in druntime? (With some modifications, of course). With
 the last compiler release, there is no longer any dependency on the DMC
 runtime. I put a lot of effort into understanding Windows SEH, and I
 believe it is quite well documented now.


I think that the compiler outputs exception tables, or something like 
that. Without does tables no exceptions.


 I need a hand with writing a good building instruction. If you want
 to help, send me a letter, I'll talk you through building process.
 By the way, druntime and phobos with ldc2 patches can be found here:
 https://github.com/AlexeyProkhin.


 I might try compiling it on Windows again.





-- 
/Jacob Carlborg
Feb 25 2011
prev sibling parent Kagamin <spam here.lot> writes:
Don Wrote:


 Wouldn't it be possible for LDC to use the exception handling 
 implementation in druntime? (With some modifications, of course). With 
 the last compiler release, there is no longer any dependency on the DMC 
 runtime. I put a lot of effort into understanding Windows SEH, and I 
 believe it is quite well documented now.


The runtime is not a problem, llvm lacks compile time support for SEH. They may
try to get sjlj to work.
Feb 25 2011
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 2/23/2011 3:00 PM, Alexey Prokhin wrote:

 LDC2 Status


 LDC2 passes almost all phobos unittests and tests from dmd suite on linux x86.
Also it probably works on freebsd, but it's broken on other platforms and
architectures.
 I currently work on linux X86_64 port: ldc2 already compiles druntime and
phobos, although there are some serious issues with GC (which make ldc2 quite
useless on 64 bits).

 Trass3r Wrote:

 Also I got the feeling that LDC2 has been hastily updated to the newest dmd
frontend without verifying each upgrade step by step and now things are subtly
broken.


 When I started to work on ldc2, it was in terrible state (it did not even
compile). So, yes, I decided to update ldc to the latest dmd frontend at the
time. But after that every frontend merge was thoroughly tested using phobos
unittests and dmd test suite.


 I need a hand with writing a good building instruction. If you want to help,
send me a letter, I'll talk you through building process.
 By the way, druntime and phobos with ldc2 patches can be found here:
https://github.com/AlexeyProkhin.


Still can't get druntime to compile.  The readme file in runtime/ is 
horribly outdated.  I cloned your github repo, and tried a few things, 
but I have no clue where I should put it, or how to build it.  It looks 
like the make file is still for DMD.
Feb 23 2011
next sibling parent Alexey Prokhin <alexey.prokhin yandex.ru> writes:
 Still can't get druntime to compile.  The readme file in runtime/ is
 horribly outdated. I cloned your github repo, and tried a few things,
 but I have no clue where I should put it, or how to build it.  It looks
 like the make file is still for DMD.


I use cmake to compile druntime and phobos:
$ cd ldc2_build_dir
$ cmake -DRUNTIME_DIR=path_to_druntime -DPHOBOS2_DIR=path_to_phobos .
$ make phobos2 (or 'make runtime' if you want to build only druntime)
Feb 23 2011
prev sibling parent reply Andrew Wiley <debio264 gmail.com> writes:
On Thu, Feb 24, 2011 at 12:56 AM, Alexey Prokhin
<alexey.prokhin yandex.ru> wrote:

 I use cmake to compile druntime and phobos:
 $ cd ldc2_build_dir
 $ cmake -DRUNTIME_DIR=path_to_druntime -DPHOBOS2_DIR=path_to_phobos .
 $ make phobos2 (or 'make runtime' if you want to build only druntime)


I tried building on ARM just for the heck of it, and ldc2 compiles
successfully, but when I compile druntime, odd things happen.
Specifically, looking at the version blocks in core/stdc/stdargs.d, I
should be getting a static assert failure because my platform is
unsupported, but instead I'm seeing this:

$ ldc2  core/stdc/stdarg.d
core/stdc/stdio.d(345): Error: undefined identifier va_list
core/stdc/stdio.d(345): Error: va_list is used as a type
core/stdc/stdio.d(346): Error: undefined identifier va_list
core/stdc/stdio.d(346): Error: va_list is used as a type
core/stdc/stdio.d(347): Error: undefined identifier va_list
core/stdc/stdio.d(347): Error: va_list is used as a type
core/stdc/stdio.d(348): Error: undefined identifier va_list
core/stdc/stdio.d(348): Error: va_list is used as a type
core/stdc/stdio.d(349): Error: undefined identifier va_list
core/stdc/stdio.d(349): Error: va_list is used as a type
core/stdc/stdio.d(350): Error: undefined identifier va_list
core/stdc/stdio.d(350): Error: va_list is used as a type
core/stdc/stdio.d(405): Error: undefined identifier va_list
core/stdc/stdio.d(405): Error: va_list is used as a type
core/stdc/wchar_.d(37): Error: undefined identifier va_list
core/stdc/wchar_.d(37): Error: va_list is used as a type
core/stdc/wchar_.d(38): Error: undefined identifier va_list
core/stdc/wchar_.d(38): Error: va_list is used as a type
core/stdc/wchar_.d(39): Error: undefined identifier va_list
core/stdc/wchar_.d(39): Error: va_list is used as a type
core/stdc/wchar_.d(40): Error: undefined identifier va_list
core/stdc/wchar_.d(40): Error: va_list is used as a type
core/stdc/wchar_.d(41): Error: undefined identifier va_list
core/stdc/wchar_.d(41): Error: va_list is used as a type
core/stdc/wchar_.d(42): Error: undefined identifier va_list
core/stdc/wchar_.d(42): Error: va_list is used as a type


This is odd because stdarg contains no import statements. Is the
compiler generating references to the other modules somehow, and if
so, why do I get these errors instead of the unsupported platform
error?
Feb 24 2011
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-02-24 10:49:31 -0500, Andrew Wiley <debio264 gmail.com> said:


 On Thu, Feb 24, 2011 at 12:56 AM, Alexey Prokhin
 <alexey.prokhin yandex.ru> wrote:

 I use cmake to compile druntime and phobos:
 $ cd ldc2_build_dir
 $ cmake -DRUNTIME_DIR=path_to_druntime -DPHOBOS2_DIR=path_to_phobos .
 $ make phobos2 (or 'make runtime' if you want to build only druntime)
 


 
 I tried building on ARM just for the heck of it, and ldc2 compiles
 successfully, but when I compile druntime, odd things happen.
 Specifically, looking at the version blocks in core/stdc/stdargs.d, I
 should be getting a static assert failure because my platform is
 unsupported, but instead I'm seeing this:
 
 $ ldc2  core/stdc/stdarg.d
 core/stdc/stdio.d(345): Error: undefined identifier va_list
 core/stdc/stdio.d(345): Error: va_list is used as a type
 core/stdc/stdio.d(346): Error: undefined identifier va_list
 core/stdc/stdio.d(346): Error: va_list is used as a type
 core/stdc/stdio.d(347): Error: undefined identifier va_list
 core/stdc/stdio.d(347): Error: va_list is used as a type
 core/stdc/stdio.d(348): Error: undefined identifier va_list
 core/stdc/stdio.d(348): Error: va_list is used as a type
 core/stdc/stdio.d(349): Error: undefined identifier va_list
 core/stdc/stdio.d(349): Error: va_list is used as a type
 core/stdc/stdio.d(350): Error: undefined identifier va_list
 core/stdc/stdio.d(350): Error: va_list is used as a type
 core/stdc/stdio.d(405): Error: undefined identifier va_list
 core/stdc/stdio.d(405): Error: va_list is used as a type
 core/stdc/wchar_.d(37): Error: undefined identifier va_list
 core/stdc/wchar_.d(37): Error: va_list is used as a type
 core/stdc/wchar_.d(38): Error: undefined identifier va_list
 core/stdc/wchar_.d(38): Error: va_list is used as a type
 core/stdc/wchar_.d(39): Error: undefined identifier va_list
 core/stdc/wchar_.d(39): Error: va_list is used as a type
 core/stdc/wchar_.d(40): Error: undefined identifier va_list
 core/stdc/wchar_.d(40): Error: va_list is used as a type
 core/stdc/wchar_.d(41): Error: undefined identifier va_list
 core/stdc/wchar_.d(41): Error: va_list is used as a type
 core/stdc/wchar_.d(42): Error: undefined identifier va_list
 core/stdc/wchar_.d(42): Error: va_list is used as a type
 
 
 This is odd because stdarg contains no import statements. Is the
 compiler generating references to the other modules somehow, and if
 so, why do I get these errors instead of the unsupported platform
 error?


The object module in druntime is always imported implicitly. You could 
try commenting everything in module object and reenabling things as you 
need them.


-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Feb 24 2011
prev sibling parent reply "huynh van sen" <huynhvansen76 gmail.com> writes:
Please build LDC2 for windowXP with visual studio 2010
I try compling on windows XP 32 bit .But I get Error
Please Help me !

C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must 
be in segment
  block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(34): error A2034: must 
be in segment
  block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(35): error A2034: must 
be in segment
  block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(36): error A2034: must 
be in segment
  block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(37): error A2034: must 
be in segment
  block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error 
A1010: unmatched bl
ock nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
Done Building Project "C:\ldcenv\build-ldc2\LDCShared.vcxproj" 
(default targets



"C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\ldcenv\build-ldc2\LDCShared.vcxproj" (default target) (2) ->
(CustomBuild target) ->
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(23): error A2013: 
.MODEL must prec
ede this directive [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(25): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(27): error A2013: 
.MODEL must prec
ede this directive [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(31): error A2034: 
must be in segme
nt block : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(32): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(34): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(35): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(36): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(37): error A2034: 
must be in segme
nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
   C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error 
A1010: unmatched
block nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]


"C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\ldcenv\build-ldc2\ldmd2.vcxproj" (default target) (8) ->
(Link target) ->
   LINK : fatal error LNK1104: cannot open file 'Program.lib' 
[C:\ldcenv\build-l
dc2\ldmd2.vcxproj]

     30 Warning(s)
     12 Error(s)

Time Elapsed 00:00:20.18

C:\ldcenv\build-ldc2>
Jul 24 2012
next sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 25.07.2012 06:28, huynh van sen wrote:

 Please build LDC2 for windowXP with visual studio 2010
 I try compling on windows XP 32 bit .But I get Error
 Please Help me !

 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be in
 segment


....

 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
 unmatched
 block nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]


 "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
 "C:\ldcenv\build-ldc2\ldmd2.vcxproj" (default target) (8) ->
 (Link target) ->
    LINK : fatal error LNK1104: cannot open file 'Program.lib'
 [C:\ldcenv\build-l
 dc2\ldmd2.vcxproj]

      30 Warning(s)
      12 Error(s)

 Time Elapsed 00:00:20.18

 C:\ldcenv\build-ldc2>


I have not tried to build LDC myself, but my guess is that there is 
something wrong with the build step for the assembly file ldfpu.asm. It 
seems the VS projects are generated from CMake, so it might not be setup 
correctly.

For x64 builds, the command line in dmd_msc.vcproj is "ml64 -c -Zi 
"-Fl$(IntDir)\$(InputName).lst" "-Fo$(IntDir)\$(InputName).obj" 
"$(InputPath)".
For win32 builds, ldfpu.asm should be excluded from the build, inline 
assembly is used instead in longdouble.c.

BTW: are there instructions how to build LDC2 on Windows? What is the 
state of the missing exception handling for Windows?
Jul 25 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-07-25 22:39, Rainer Schuetze wrote:


 What is the state of the missing exception handling for Windows?


I just read an old post on the Clang mailing list, it's not looking 
good. It seems Microsoft (or someone else) has a patent on SEH, which 
basically means: never gonna happen. An alternative could be 
setjmp/longjmp. On 64bit it looks a bit better, where the correct way 
seems to be to use the Win64 exception ABI.

http://clang-developers.42468.n3.nabble.com/LLVM-Clang-and-setjmp-longjmp-exception-handling-on-MinGW-td3407322.html

http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

-- 
/Jacob Carlborg
Jul 26 2012
parent reply Don Clugston <dac nospam.com> writes:
On 26/07/12 09:05, Jacob Carlborg wrote:

 On 2012-07-25 22:39, Rainer Schuetze wrote:


 What is the state of the missing exception handling for Windows?


 I just read an old post on the Clang mailing list, it's not looking
 good. It seems Microsoft (or someone else) has a patent on SEH,


I've heard this, but does anyone know what patent is being referred to? 
Several times I've heard mention of an old one by Borland, which 
Microsoft bought. The Borland patent is not a patent on SEH, it's 
basically a patent on using a thunk. I suspect it is extremely unlikely 
to be a valid patent, for sure there is prior art. And the only reason 
for implementing it with a thunk anyway, is as a workaround for the 
broken thread-local support in Windows prior to Vista.

It's not difficult to implement SEH without violating that patent (which 
is due to expire soon anyway). Is there some other patent that people 
are referring to?


which

 basically means: never gonna happen. An alternative could be
 setjmp/longjmp. On 64bit it looks a bit better, where the correct way
 seems to be to use the Win64 exception ABI.


Win64 SEH is scarcely any different to Win32 SEH, it's just better 
documented. You can do the same thing on Win32.



 http://clang-developers.42468.n3.nabble.com/LLVM-Clang-and-setjmp-longjmp-exception-handling-on-MinGW-td3407322.html


 http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx


The situation makes no sense to me.
Jul 31 2012
next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 31 July 2012 at 11:21:21 UTC, Don Clugston wrote:

 Win64 SEH is scarcely any different to Win32 SEH, it's just 
 better documented. You can do the same thing on Win32.


Unless I'm mistaken, SEH on Win64 is quite a lot different to 
Win32, as it is based on tables, rather than keeping FS:[0] up to 
date in the function pro-/epilogues.

David
Jul 31 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-07-31 13:21, Don Clugston wrote:


 I've heard this, but does anyone know what patent is being referred to?
 Several times I've heard mention of an old one by Borland, which
 Microsoft bought. The Borland patent is not a patent on SEH, it's
 basically a patent on using a thunk. I suspect it is extremely unlikely
 to be a valid patent, for sure there is prior art. And the only reason
 for implementing it with a thunk anyway, is as a workaround for the
 broken thread-local support in Windows prior to Vista.


I think it's this patent:

http://www.google.com/patents/about?id=21MgAAAAEBAJ&dq=5,628,016

Inventor: Peter Kukol
Original Assignee: Borland International, Inc.
Primary Examiner: Peter J. Corcoran, III
Current U.S. Classification: 717/140; 717/114
International Classification: G06F 945


 It's not difficult to implement SEH without violating that patent (which
 is due to expire soon anyway). Is there some other patent that people
 are referring to?


It doesn't matter. The Clang/LLVM developers won't accept an 
implementation that has any chance of being covered by a patent.

-- 
/Jacob Carlborg
Jul 31 2012
prev sibling parent reply Kai Nacke <kai redstar.de> writes:
On 25.07.2012 22:39, Rainer Schuetze wrote:

 On 25.07.2012 06:28, huynh van sen wrote:

 Please build LDC2 for windowXP with visual studio 2010
 I try compling on windows XP 32 bit .But I get Error
 Please Help me !

 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be in
 segment


 ....

 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
 unmatched
 block nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]


 "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
 "C:\ldcenv\build-ldc2\ldmd2.vcxproj" (default target) (8) ->
 (Link target) ->
    LINK : fatal error LNK1104: cannot open file 'Program.lib'
 [C:\ldcenv\build-l
 dc2\ldmd2.vcxproj]

      30 Warning(s)
      12 Error(s)

 Time Elapsed 00:00:20.18

 C:\ldcenv\build-ldc2>


 I have not tried to build LDC myself, but my guess is that there is
 something wrong with the build step for the assembly file ldfpu.asm. It
 seems the VS projects are generated from CMake, so it might not be setup
 correctly.

 For x64 builds, the command line in dmd_msc.vcproj is "ml64 -c -Zi
 "-Fl$(IntDir)\$(InputName).lst" "-Fo$(IntDir)\$(InputName).obj"
 "$(InputPath)".
 For win32 builds, ldfpu.asm should be excluded from the build, inline
 assembly is used instead in longdouble.c.

 BTW: are there instructions how to build LDC2 on Windows? What is the
 state of the missing exception handling for Windows?


Hi!

Thanks for the hint. I try to correct the build file generation. Because 
of missing SEH support (protected by patents :-( ), I only work on the 
x64 version of LDC.

Build instructions are here:
https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on-Windows-using-MSVC

Regards
Kai
Jul 28 2012
next sibling parent reply "Kagamin" <spam here.lot> writes:
Dwarf2 exceptions work in clang+gcc on win32. It would be SOME 
exception handling (and quite interesting, I'd say).
Aug 04 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-04 17:20, Kagamin wrote:

 Dwarf2 exceptions work in clang+gcc on win32. It would be SOME exception
 handling (and quite interesting, I'd say).


This post recently appeared on the Clang mailing list:

"Hi,

I have just been made aware that GCC 4.7.2 and later will use SEH by 
default on Win64:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html

I would like to inquire as to possibility of this being implemented in 
Clang/LLVM. As this type of exception handling is much closer to the 
classic Dwarf model currently used, I hope it won't be too difficult to 
implement this in Clang? Remember that Win64 EH is broken right now, so 
any improvement is the right improvement ;-)

For 32-bit dw2 eh already works well, and in light of the misty Borland 
patents will probably remain the only option for a while.

Thanks!

Ruben

PS: please also reply to my email address, as I'm not subscribed to cfe-dev"


-- 
/Jacob Carlborg
Aug 04 2012
parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
On Saturday, 4 August 2012 at 16:11:45 UTC, Jacob Carlborg wrote:

 On 2012-08-04 17:20, Kagamin wrote:

 Dwarf2 exceptions work in clang+gcc on win32. It would be SOME 
 exception
 handling (and quite interesting, I'd say).


 This post recently appeared on the Clang mailing list:

 "Hi,

 I have just been made aware that GCC 4.7.2 and later will use 
 SEH by default on Win64:
 http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html

 I would like to inquire as to possibility of this being 
 implemented in Clang/LLVM. As this type of exception handling 
 is much closer to the classic Dwarf model currently used, I 
 hope it won't be too difficult to implement this in Clang? 
 Remember that Win64 EH is broken right now, so any improvement 
 is the right improvement ;-)

 For 32-bit dw2 eh already works well, and in light of the misty 
 Borland patents will probably remain the only option for a 
 while.

 Thanks!

 Ruben

 PS: please also reply to my email address, as I'm not 
 subscribed to cfe-dev"


Charles Davis did a lot of work on Win64 SEH support in LLVM,
check commits r131652-r132880.

It's not finished yet. All the stuff for assembly code that uses
Win64 EH is done, but not the code-gen-side stuff (cf.
Win64Exception class in CodeGen). I was about to finish it, but
then real life happened :). This would have allowed us to use
DW2-style EH on Win64, but it still would have been problematic
for VC++ EH.

Kai Tietz was interested in finishing it, so I emailed him what I
have. I assume he's been working on it--he recently submitted a
patch to fix the permissions on .pdata/.xdata sections that I got
wrong :). I've CC'd him as well so we can see what he has for us.

Chip

It sounds like this should be targetable from ldc now.
Aug 04 2012
next sibling parent "Hans W. Uhlig" <huhlig gmail.com> writes:
On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:

 On Saturday, 4 August 2012 at 16:11:45 UTC, Jacob Carlborg 
 wrote:

 On 2012-08-04 17:20, Kagamin wrote:

 Dwarf2 exceptions work in clang+gcc on win32. It would be 
 SOME exception
 handling (and quite interesting, I'd say).


 This post recently appeared on the Clang mailing list:

 "Hi,

 I have just been made aware that GCC 4.7.2 and later will use 
 SEH by default on Win64:
 http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00512.html

 I would like to inquire as to possibility of this being 
 implemented in Clang/LLVM. As this type of exception handling 
 is much closer to the classic Dwarf model currently used, I 
 hope it won't be too difficult to implement this in Clang? 
 Remember that Win64 EH is broken right now, so any improvement 
 is the right improvement ;-)

 For 32-bit dw2 eh already works well, and in light of the 
 misty Borland patents will probably remain the only option for 
 a while.

 Thanks!

 Ruben

 PS: please also reply to my email address, as I'm not 
 subscribed to cfe-dev"


 Charles Davis did a lot of work on Win64 SEH support in LLVM,
 check commits r131652-r132880.

 It's not finished yet. All the stuff for assembly code that uses
 Win64 EH is done, but not the code-gen-side stuff (cf.
 Win64Exception class in CodeGen). I was about to finish it, but
 then real life happened :). This would have allowed us to use
 DW2-style EH on Win64, but it still would have been problematic
 for VC++ EH.

 Kai Tietz was interested in finishing it, so I emailed him what 
 I
 have. I assume he's been working on it--he recently submitted a
 patch to fix the permissions on .pdata/.xdata sections that I 
 got
 wrong :). I've CC'd him as well so we can see what he has for 
 us.

 Chip

 It sounds like this should be targetable from ldc now.


http://www.nynaeve.net/?p=113
Aug 04 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:

 It sounds like this should be targetable from ldc now.


Hm? It's great that the bigger part of Charles' work has arrived 
in trunk in June or so, but what's still completely missing is 
landing pad codegen – isn't it?

David
Aug 05 2012
parent reply =?UTF-8?B?Ikpvw6Nv?= Matos" <ripzonetriton gmail.com> writes:
On Sunday, 5 August 2012 at 09:56:09 UTC, David Nadlinger wrote:

 On Saturday, 4 August 2012 at 23:35:30 UTC, Hans W. Uhlig wrote:

 It sounds like this should be targetable from ldc now.


 Hm? It's great that the bigger part of Charles' work has 
 arrived in trunk in June or so, but what's still completely 
 missing is landing pad codegen – isn't it?

 David


I think so. I'll be taking a look at this soon, I'm interested in 
getting it to work on Windows. If someone wants to collaborate on 
it, feel free to mail me.
Aug 05 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 5 August 2012 at 16:10:51 UTC, João Matos wrote:

 I think so. I'll be taking a look at this soon, I'm interested 
 in getting it to work on Windows. If someone wants to 
 collaborate on it, feel free to mail me.


I'd be happy to help if you have any questions regarding the LDC 
side of things. As for the actual implementation, I guess I have 
to pass, even though I have a pretty good understanding of SEH 
right now, because I'm right in the middle of an exam session at 
university right now. My plan was to have a look at this in 
September or so, but I'll gladly work on ARM support instead.

David
Aug 06 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/28/12, Kai Nacke <kai redstar.de> wrote:

 Build instructions are here:
 https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on-Windows-using-MSVC


Can LDC compile D apps that use Phobos? It says "never tried to use
Phobos" here: https://github.com/ldc-developers/ldc/wiki/Project-Status

Does that apply only for 64bit builds? I'm interested in a 32bit build.
Aug 06 2012
parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 6 August 2012 at 15:28:04 UTC, Andrej Mitrovic wrote:

 Can LDC compile D apps that use Phobos? It says "never tried to 
 use
 Phobos" here: 
 https://github.com/ldc-developers/ldc/wiki/Project-Status

 Does that apply only for 64bit builds? I'm interested in a 
 32bit build.


This only applies to Windows, which is in general pretty much 
uncharted territory. Once in a while, someone (including me) 
tries to use it for their own projects and fixes the necessary 
stuff, but it has never reached the »supported« status due to 
lack of exception support (both 32 bit/64 bit).

Also note that Kai is specifically interested in building LDC 
using MSVC. Using MinGW, I was able to get LDC2/Phobos to work on 
32 bit Windows pretty straightforwardly some time ago, but again, 
there is no exception support yet.

David
Aug 06 2012
prev sibling parent Kai Nacke <kai redstar.de> writes:
Hi huynh van sen!

This is fixed now. Please try again.

Regards
Kai

On 25.07.2012 06:28, huynh van sen wrote:

 Please build LDC2 for windowXP with visual studio 2010
 I try compling on windows XP 32 bit .But I get Error
 Please Help me !

 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be in
 segment
   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(34): error A2034: must be in
 segment
   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(35): error A2034: must be in
 segment
   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(36): error A2034: must be in
 segment
   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(37): error A2034: must be in
 segment
   block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
 C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
 unmatched bl
 ock nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
 Done Building Project "C:\ldcenv\build-ldc2\LDCShared.vcxproj" (default
 targets



 "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
 "C:\ldcenv\build-ldc2\LDCShared.vcxproj" (default target) (2) ->
 (CustomBuild target) ->
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(23): error A2013: .MODEL
 must prec
 ede this directive [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(25): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(27): error A2013: .MODEL
 must prec
 ede this directive [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(31): error A2034: must be
 in segme
 nt block : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(32): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(33): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(34): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(35): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(36): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(37): error A2034: must be
 in segme
 nt block [C:\ldcenv\build-ldc2\LDCShared.vcxproj]
    C:/ldcenv/build-ldc2/ldc/vcbuild/ldfpu.asm(38): fatal error A1010:
 unmatched
 block nesting : ld_read [C:\ldcenv\build-ldc2\LDCShared.vcxproj]


 "C:\ldcenv\build-ldc2\ALL_BUILD.vcxproj" (default target) (1) ->
 "C:\ldcenv\build-ldc2\ldmd2.vcxproj" (default target) (8) ->
 (Link target) ->
    LINK : fatal error LNK1104: cannot open file 'Program.lib'
 [C:\ldcenv\build-l
 dc2\ldmd2.vcxproj]

      30 Warning(s)
      12 Error(s)

 Time Elapsed 00:00:20.18

 C:\ldcenv\build-ldc2>
Jul 29 2012
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 22/02/11 23:52, dsimcha wrote:

 I tried LDC2 for Linux out last week and again last night. I didn't
 spend much time on it on either attempt, but so far I haven't been able
 to get even Hello, World to compile. It seems like the instructions for
 building druntime, etc. are horribly outdated, the patches bit rotted,
 etc. Has anyone managed to get past these hurdles and compile Hello,
 World lately? If so, would you mind posting some instructions? If LDC2
 is, in fact, mature enough that it would be worthwhile, I'd like to test
 it out, file bug reports, etc.


LDC2 has a way to go before being D2 ready, gdc is far further along. 
 From what I can gather, the following should compile ldc, druntime and 
phobos, it seems (very) broken currently though - best to get in touch 
with the guy working on it - I have a feeling he's using an old version 
of druntime.

hg clone https://bitbucket.org/prokhin_alexey/ldc2
cd ldc2
git clone https://github.com/D-Programming-Language/druntime
git clone https://github.com/D-Programming-Language/phobos
ccmake .


make phobos2

-- 
Robert
http://octarineparrot.com/
Feb 23 2011
parent Robert Clipsham <robert octarineparrot.com> writes:
On 23/02/11 21:15, Robert Clipsham wrote:

 On 22/02/11 23:52, dsimcha wrote:

 I tried LDC2 for Linux out last week and again last night. I didn't
 spend much time on it on either attempt, but so far I haven't been able
 to get even Hello, World to compile. It seems like the instructions for
 building druntime, etc. are horribly outdated, the patches bit rotted,
 etc. Has anyone managed to get past these hurdles and compile Hello,
 World lately? If so, would you mind posting some instructions? If LDC2
 is, in fact, mature enough that it would be worthwhile, I'd like to test
 it out, file bug reports, etc.


 LDC2 has a way to go before being D2 ready, gdc is far further along.
  From what I can gather, the following should compile ldc, druntime and
 phobos, it seems (very) broken currently though - best to get in touch
 with the guy working on it - I have a feeling he's using an old version
 of druntime.

 hg clone https://bitbucket.org/prokhin_alexey/ldc2
 cd ldc2
 git clone https://github.com/D-Programming-Language/druntime
 git clone https://github.com/D-Programming-Language/phobos
 ccmake .


 make phobos2


Scrap that, Alexy just replied with far better information!

-- 
Robert
http://octarineparrot.com/
Feb 23 2011