www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - LDC 0.12.1 has been released

reply "Kai Nacke" <kai redstar.de> writes:
Hi everyone,

The new LDC release 0.12.1 is here! This is a bug-fix only 
release based on the 2.063.2 front-end and LLVM 3.1-3.3 (OS X: 
LLVM 3.2 only).

Please refer to the GitHub release page for the change log and 
the package download links:
https://github.com/ldc-developers/ldc/releases/tag/v0.12.1

MD5 checksums for the release packages:

900696b2f83f52ea354522f3caa5d217  ldc-0.12.1-src.tar.gz
669f6546e8ac52ef69409135d009e644  ldc2-0.12.1-linux-x86.tar.gz
faedb93db9e65fd03f8e36167eb16100  ldc2-0.12.1-linux-x86.tar.xz
053ac40de47da7e1bfcc390fc9ad922b  ldc2-0.12.1-linux-x86_64.tar.gz
e001c9db05c702097bc626ea0d92c4ac  ldc2-0.12.1-linux-x86_64.tar.xz
de315544d5eb59e94216eac39dcebad6  ldc2-0.12.1-mingw-x86.7z
3c736ff55339bf47d8cdd92a857693d1  ldc2-0.12.1-mingw-x86.zip
d5ebf934493a2b15bc633bf5903eb689  ldc2-0.12.1-osx-x86_64.tar.gz
7ff99f0706950bea43ad01ae4f530cae  ldc2-0.12.1-osx-x86_64.tar.xz

As always, the Win32/MinGW packages require a recent version of 
the mingw-w64 toolchain, see the (new) README file for details. 
There are no packages for the Win64/MSVC port yet. But you may 
want to have a look at the package provided by tae hoo:
http://forum.dlang.org/thread/wrzsaoppngemvqikusac forum.dlang.org

Please be sure to report any bugs at
https://github.com/ldc-developers/ldc/issues, and feel free to 
drop by at the digitalmars.D.ldc forums
(http://forum.dlang.org/group/digitalmars.D.ldc) for any 
questions or
comments.

Thanks to everybody involved in making this happen!

Regards,
Kai
Dec 01 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Kai Nacke:


 669f6546e8ac52ef69409135d009e644  ldc2-0.12.1-linux-x86.tar.gz


I have tried ldc2-0.12.1-linux-x86.tar.gz and I works for me.

Bye,
bearophile
Dec 02 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 2 Dec 2013, at 16:21, bearophile wrote:

 Kai Nacke:


 669f6546e8ac52ef69409135d009e644  ldc2-0.12.1-linux-x86.tar.gz


 I have tried ldc2-0.12.1-linux-x86.tar.gz and I works for me.


Thanks for the feedback!

David
Dec 02 2013
parent reply "Steve" <steve domain.org> writes:
The executables in the 386 gzip file are for the 64-bit systems, 
and don't run on 386 boxes.
Dec 03 2013
next sibling parent reply "Kai Nacke" <kai redstar.de> writes:
Hi Steve!

On Wednesday, 4 December 2013 at 02:38:39 UTC, Steve wrote:

 The executables in the 386 gzip file are for the 64-bit 
 systems, and don't run on 386 boxes.


I will fix it. (Haven't checked yet but it can be possible. It 
was the first release I produced. I apologize for any 
inconvinience here.)

Regards,
Kai
Dec 04 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 4 Dec 2013, at 11:44, Kai Nacke wrote:

 I will fix it. (Haven't checked yet but it can be possible. It was the 
 first release I produced. I apologize for any inconvinience here.)


Note: The packaging scripts always produce native compiler binaries, the 
set/detected ARCH isn't used for "cross-compilation" (i.e., -m32 here). 
I didn't try doing that because I wanted to avoid any compatibility 
problems from the start, and just use an x86 Ubuntu EC2 instance for 
creating the packages.

David
Dec 04 2013
parent "Kai Nacke" <kai redstar.de> writes:
On Thursday, 5 December 2013 at 01:15:01 UTC, David Nadlinger 
wrote:

 Note: The packaging scripts always produce native compiler 
 binaries, the set/detected ARCH isn't used for 
 "cross-compilation" (i.e., -m32 here). I didn't try doing that 
 because I wanted to avoid any compatibility problems from the 
 start, and just use an x86 Ubuntu EC2 instance for creating the 
 packages.


Yes, that's what happened. I used Ubuntu x86_64 to produce the 
x86 binary. :-(

Regards,
Kai
Dec 04 2013
prev sibling parent reply "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 4 December 2013 at 02:38:39 UTC, Steve wrote:

 The executables in the 386 gzip file are for the 64-bit 
 systems, and don't run on 386 boxes.


Hi Steve,

I uploaded a new x86-version - this time as 32bit build.

The md5 sums are:

955ccbd98dfa7f8a4e63a8094794e92c  ldc2-0.12.1-linux-x86.tar.gz
a9a865c211252e878e2e0764d3c4c469  ldc2-0.12.1-linux-x86.tar.xz

Thanks again for pointing out the problem!

Regards,
Kai
Dec 08 2013
parent reply "Steve" <steve domain.org> writes:
Hi Kai,

Thanks for the fix.  That solved the 64-bit issue.  
Unfortunately, now I get:

ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version 
`GLIBC_2.15' not found (required by ldc2)

I'm running on Crunchbang Waldorf release, adn that version of 
libc isn't available yet.

Steve


On Sunday, 8 December 2013 at 14:58:48 UTC, Kai Nacke wrote:

 On Wednesday, 4 December 2013 at 02:38:39 UTC, Steve wrote:

 The executables in the 386 gzip file are for the 64-bit 
 systems, and don't run on 386 boxes.


 Hi Steve,

 I uploaded a new x86-version - this time as 32bit build.

 The md5 sums are:

 955ccbd98dfa7f8a4e63a8094794e92c  ldc2-0.12.1-linux-x86.tar.gz
 a9a865c211252e878e2e0764d3c4c469  ldc2-0.12.1-linux-x86.tar.xz

 Thanks again for pointing out the problem!

 Regards,
 Kai
Dec 10 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
Hi Steve!

On Tuesday, 10 December 2013 at 17:48:40 UTC, Steve wrote:

 Thanks for the fix.  That solved the 64-bit issue.  
 Unfortunately, now I get:

 ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version 
 `GLIBC_2.15' not found (required by ldc2)


I try to fix this, too.

Regards,
Kai
Dec 16 2013
next sibling parent "Steve" <steve domain.org> writes:
On Monday, 16 December 2013 at 16:54:58 UTC, Kai Nacke wrote:

 Hi Steve!

 On Tuesday, 10 December 2013 at 17:48:40 UTC, Steve wrote:

 Thanks for the fix.  That solved the 64-bit issue.  
 Unfortunately, now I get:

 ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version 
 `GLIBC_2.15' not found (required by ldc2)


 I try to fix this, too.

 Regards,
 Kai



Hi Kai,

I just checked and the same is true for the 64-bit version as 
well.

Steve
Dec 17 2013
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Monday, 16 December 2013 at 16:54:58 UTC, Kai Nacke wrote:

 On Tuesday, 10 December 2013 at 17:48:40 UTC, Steve wrote:

 Thanks for the fix.  That solved the 64-bit issue.  
 Unfortunately, now I get:

 ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version 
 `GLIBC_2.15' not found (required by ldc2)


 I try to fix this, too.


Did you build the binaries on Ubuntu 10.04 LTS, as mentioned on 
the release page? The point of this is to link against a glibc 
that is old enough that we can expect people to have at least 
that version on their systems.

David
Dec 17 2013
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/01/2013 10:59 PM, Kai Nacke wrote:

 Hi everyone,


Just built it from source with BUILD_SHARED_LIBS=ON. It compiles me a 
shared library with minimal fuss! But, as with dmd, it doesn't 
initialize druntime (main is in C). Until it does, does ldc have an 
equivalent to gcc's

__attribute__((__constructor__))
__attribute__((__destructor__))

?
Dec 04 2013
next sibling parent reply "Kai Nacke" <kai redstar.de> writes:
Hi Ellery!

On Thursday, 5 December 2013 at 01:25:06 UTC, Ellery Newcomer 
wrote:

 On 12/01/2013 10:59 PM, Kai Nacke wrote:

 Hi everyone,


 Just built it from source with BUILD_SHARED_LIBS=ON. It 
 compiles me a shared library with minimal fuss! But, as with 
 dmd, it doesn't initialize druntime (main is in C). Until it 
 does, does ldc have an equivalent to gcc's

 __attribute__((__constructor__))
 __attribute__((__destructor__))

 ?


Shared libraries are not yet supported and still need some work.

I don't know the semantic of the gcc attributes. Do 
pragma(LDC_global_crt_ctor) and pragma(LDC_global_crt_dtor) help? 
See http://wiki.dlang.org/LDC-specific_language_changes.

Regards,
kai
Dec 04 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-12-05 07:52, Kai Nacke wrote:


 Shared libraries are not yet supported and still need some work.

 I don't know the semantic of the gcc attributes. Do
 pragma(LDC_global_crt_ctor) and pragma(LDC_global_crt_dtor) help? See
 http://wiki.dlang.org/LDC-specific_language_changes.


The functions the attributes are attached to will be called before a 
shared library is loaded/unloaded. Clang supports these as well.

-- 
/Jacob Carlborg
Dec 04 2013
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/04/2013 10:52 PM, Kai Nacke wrote:

 Shared libraries are not yet supported and still need some work.


yes, but I am impatient.


 I don't know the semantic of the gcc attributes. Do
 pragma(LDC_global_crt_ctor) and pragma(LDC_global_crt_dtor) help? See
 http://wiki.dlang.org/LDC-specific_language_changes.

 Regards,
 kai


This should be just what I need. Thanks!
Dec 05 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Friday, 6 December 2013 at 01:14:26 UTC, Ellery Newcomer wrote:

 On 12/04/2013 10:52 PM, Kai Nacke wrote:

 Shared libraries are not yet supported and still need some 
 work.


 yes, but I am impatient.


Maybe you can help with the implementation in LDC? This is one of 
the most-wanted features.

Regards,
Kai
Dec 06 2013
next sibling parent reply "Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:
On Friday, 6 December 2013 at 15:39:17 UTC, Kai Nacke wrote:

 Maybe you can help with the implementation in LDC? This is one 
 of the most-wanted features.

 Regards,
 Kai


Well, what needs to be done yet?
Dec 06 2013
parent "Kai Nacke" <kai redstar.de> writes:
On Friday, 6 December 2013 at 18:38:28 UTC, Ellery Newcomer wrote:

 On Friday, 6 December 2013 at 15:39:17 UTC, Kai Nacke wrote:

 Maybe you can help with the implementation in LDC? This is one 
 of the most-wanted features.

 Regards,
 Kai


 Well, what needs to be done yet?


David pointed already to the merge-2.064 which already contains 
some work.
I think this commit discussion provides a lot of background:
https://github.com/ldc-developers/ldc/commit/d9b137bb450601512dac4062a92e665c8017d737#commitcomment-4742502

Regards,
Kai
Dec 07 2013
prev sibling parent David Nadlinger <code klickverbot.at> writes:
Yes, that would be great!

On the 2.064 branch, I already incorporated Martin's DMD/druntime work
regarding ModuleInfo emission/lookup into our codegen. This should
already go quite a long way towards runtime loading. What's left at
this point is testing and ironing out the bugs that are undoubtedly
still in there.

Feel free to contact me with any questions.

David


---
Sent from a mobile device.


On Fri, Dec 6, 2013 at 4:39 PM, Kai Nacke <kai redstar.de> wrote:

 On Friday, 6 December 2013 at 01:14:26 UTC, Ellery Newcomer wrote:

 On 12/04/2013 10:52 PM, Kai Nacke wrote:

 Shared libraries are not yet supported and still need some work.



 yes, but I am impatient.



 Maybe you can help with the implementation in LDC? This is one of the
 most-wanted features.

 Regards,
 Kai
Dec 06 2013
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 12/04/2013 05:25 PM, Ellery Newcomer wrote:

 On 12/01/2013 10:59 PM, Kai Nacke wrote:

 Hi everyone,


 Just built it from source with BUILD_SHARED_LIBS=ON. It compiles me a
 shared library with minimal fuss! But, as with dmd, it doesn't
 initialize druntime (main is in C). Until it does, does ldc have an
 equivalent to gcc's

 __attribute__((__constructor__))
 __attribute__((__destructor__))

 ?


there wouldn't happen to be any quick way to determine if a ldc build 
has been built with BUILD_SHARED_LIBS=ON, would there?
Dec 10 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On 11 Dec 2013, at 3:59, Ellery Newcomer wrote:

 there wouldn't happen to be any quick way to determine if a ldc build 
 has been built with BUILD_SHARED_LIBS=ON, would there?


There is no difference as far as the compiler is concerned, the switch 
just builds druntime/Phobos as shared libraries.

David
Dec 11 2013
prev sibling parent reply "Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:
On Monday, 2 December 2013 at 06:59:55 UTC, Kai Nacke wrote:

 As always, the Win32/MinGW packages require a recent version of 
 the mingw-w64 toolchain, see the (new) README file for details. 
 There are no packages for the Win64/MSVC port yet. But you may 
 want to have a look at the package provided by tae hoo:
 http://forum.dlang.org/thread/wrzsaoppngemvqikusac forum.dlang.org



just installed the mingw package to windows 7 after mingw 4.7.2, 
and I get the following on attemping to compile an empty main 
function:

C:/Users/ellery/Downloads/ldc2-0.12.1-mingw-x86/ldc2-0.12.1-mingw-x86/bin/../lib/libphobos-ldc.a(demangle.obj):fake:(.te
xt+0xa9b): undefined reference to `__mingw_strtold'
collect2.exe: error: ld returned 1 exit status
Error: C:/MinGW/bin/gcc.exe failed with status: 1

what might this be about?
Dec 08 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 8 Dec 2013, at 20:20, Ellery Newcomer wrote:

 just installed the mingw package to windows 7 after mingw 4.7.2, and I 
 get the following on attemping to compile an empty main function:


Which package did you use? There is a difference between the mingw.org 
and mingw-w64 projects, and I don't know whether the former incorporates 
the required functionality yet. Could you try the mingw-w64 release 
linked in the LDC readme?

David
Dec 08 2013
parent reply "Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:
On Sunday, 8 December 2013 at 19:27:55 UTC, David Nadlinger wrote:

 On 8 Dec 2013, at 20:20, Ellery Newcomer wrote:

 just installed the mingw package to windows 7 after mingw 
 4.7.2, and I get the following on attemping to compile an 
 empty main function:


 Which package did you use? There is a difference between the 
 mingw.org and mingw-w64 projects, and I don't know whether the 
 former incorporates the required functionality yet. Could you 
 try the mingw-w64 release linked in the LDC readme?

 David


probably not. This is a 32bit system
Dec 08 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On 8 Dec 2013, at 21:10, Ellery Newcomer wrote:

 probably not. This is a 32bit system


The mingw-w64 project also offers builds for 32-bit Windows.

Just try the one linked in the readme that came with the binary package 
– if such a file mentions a required dependency in *BIG* *LETTERS* 
*WITH* *STARS*, there is usually a reason for it. ;)

David
Dec 08 2013