www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - FreeBSD port

reply Gour <gour atmarama.net> writes:
Hello,

I'm considering to move to FreeBSD and use D again, but situation with
the port is not blissful:

- ldc-devel 0.9.2.r1697_1
- BROKEN: does not compile
- DEPRECATED: Broken for more than 6 month
- EXPIRATION DATE: 2013-08-27
- IGNORE: is marked as broken: does not compile D frontend for llvm,
  with the Tango standard library

What is the prospect of using LDC on FreeBSD?


Sincerely,
Gour

-- 
One must deliver himself with the help of his mind, and not 
degrade himself. The mind is the friend of the conditioned soul, 
and his enemy as well.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Aug 24 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Saturday, 24 August 2013 at 10:19:49 UTC, Gour wrote:

 Hello,

 I'm considering to move to FreeBSD and use D again, but 
 situation with
 the port is not blissful:

 - ldc-devel 0.9.2.r1697_1


Hi Gour,

the mentioned port is out-of-date. :-(

As there are some issues reported on FreeBSD I now try to setup a 
FreeBSD image and fix the issues.

Kai
Aug 24 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
Hi,

On 24 Aug 2013, at 13:45, Kai Nacke wrote:

 As there are some issues reported on FreeBSD I now try to setup a 
 FreeBSD image and fix the issues.


Great! I suppose I should set up a VM for testing at some point as 
well…

I also just updated my comment in 
https://github.com/ldc-developers/ldc/issues/451; if the mechanism used 
isn't similar to any of the other OSes, this could be quite a trip down 
the (FreeBSD libc) rabbit hole (the thread startup code would be a good 
place to start looking).

David
Aug 24 2013
next sibling parent "Kai Nacke" <kai redstar.de> writes:
On Saturday, 24 August 2013 at 12:04:11 UTC, David Nadlinger 
wrote:

 Hi,

 On 24 Aug 2013, at 13:45, Kai Nacke wrote:

 As there are some issues reported on FreeBSD I now try to 
 setup a FreeBSD image and fix the issues.


 Great! I suppose I should set up a VM for testing at some point 
 as well…


I have now a FreeBSD VirtualBox image running (just use the 
FreeBSD 9.1 release) and hit issue 451 
(https://github.com/ldc-developers/ldc/issues/451).

Kai
Aug 24 2013
prev sibling parent reply Gour <gour atmarama.net> writes:
On Sat, 24 Aug 2013 14:03:54 +0200
"David Nadlinger" <code klickverbot.at> wrote:


 I also just updated my comment in 
 https://github.com/ldc-developers/ldc/issues/451; if the mechanism
 used isn't similar to any of the other OSes, this could be quite a
 trip down the (FreeBSD libc) rabbit hole (the thread startup code
 would be a good place to start looking).


Considering FreeBSD's move to clang/llvm, it would be great to have ldc
as well..


Sincerely,
Gour

-- 
He who is satisfied with gain which comes of its own accord, who 
is free from duality and does not envy, who is steady in both 
success and failure, is never entangled, although performing actions.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Aug 25 2013
parent reply "Kai Nacke" <kai redstar.de> writes:
On Sunday, 25 August 2013 at 11:07:13 UTC, Gour wrote:

 Considering FreeBSD's move to clang/llvm, it would be great to 
 have ldc
 as well..


Sure, I try to get it working.

If you like you could try it yourself.

To use the Git version:
- in rt.sections_ldc.d replace line 297 (static assert ...) with 
return null
- replace the gc with the file from gcstub
then you can compile&run D programs with LDC. (This disables the 
garbage collector. With this setup only 21 tests fail out of 
1044.)

The real problem seems to be that not the right memory ranges are 
advertised to the GC and therefore the GC crashes.

Regards
Kai
Aug 27 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-27 22:11, Kai Nacke wrote:


 The real problem seems to be that not the right memory ranges are
 advertised to the GC and therefore the GC crashes.


DMD works on FreeBSD, so just use the code from the standard runtime?

-- 
/Jacob Carlborg
Aug 27 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On 28 Aug 2013, at 8:25, Jacob Carlborg wrote:

 On 2013-08-27 22:11, Kai Nacke wrote:


 The real problem seems to be that not the right memory ranges are
 advertised to the GC and therefore the GC crashes.


 DMD works on FreeBSD, so just use the code from the standard runtime?


Thanks for the suggestion, but no, we can't – DMD emits custom 
bracketing symbols for the TLS section, which we can't do (at least 
without messing with backend to a point where we can't use the standard 
LLVM tools like llc/… anymore).

David
Aug 28 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-28 10:13, David Nadlinger wrote:


 Thanks for the suggestion, but no, we can't – DMD emits custom
 bracketing symbols for the TLS section, which we can't do (at least
 without messing with backend to a point where we can't use the standard
 LLVM tools like llc/… anymore).


Right... it's always these TLS sections/variables causing problems :(

-- 
/Jacob Carlborg
Aug 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-28 10:13, David Nadlinger wrote:


 Thanks for the suggestion, but no, we can't – DMD emits custom
 bracketing symbols for the TLS section, which we can't do (at least
 without messing with backend to a point where we can't use the standard
 LLVM tools like llc/… anymore).


So how much different is the FreeBSD code compared to the Linux code in 
this case?

-- 
/Jacob Carlborg
Aug 28 2013
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 28 August 2013 at 11:27:40 UTC, Jacob Carlborg 
wrote:

 On 2013-08-28 10:13, David Nadlinger wrote:

 Thanks for the suggestion, but no, we can't – DMD emits custom
 bracketing symbols for the TLS section, which we can't do (at 
 least
 without messing with backend to a point where we can't use the 
 standard
 LLVM tools like llc/… anymore).


 So how much different is the FreeBSD code compared to the Linux 
 code in this case?


I don't really have any experience with FreeBSD internals at all, 
so I can't really judge the situation, but if the BSD libc 
allocates TLS variables for new threads the same as the GNU libc 
does (i.e. at the start of the new stack), then it is potentially 
very little difference (as the ELF section iteration mechanism 
also seems to be supported).

I don't think this will be an extremely hard issue to solve, but 
it depends on somebody actually spending some time on this (and 
for myself, a 2.063-based release, Linux shared libraries, and 
the Win32 wrong code bugs seem more important, given that FreeBSD 
is a pretty niche OS…)

David
Aug 28 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-28 19:57, David Nadlinger wrote:


 I don't really have any experience with FreeBSD internals at all, so I
 can't really judge the situation, but if the BSD libc allocates TLS
 variables for new threads the same as the GNU libc does (i.e. at the
 start of the new stack), then it is potentially very little difference
 (as the ELF section iteration mechanism also seems to be supported).

 I don't think this will be an extremely hard issue to solve, but it
 depends on somebody actually spending some time on this (and for myself,
 a 2.063-based release, Linux shared libraries, and the Win32 wrong code
 bugs seem more important, given that FreeBSD is a pretty niche OS…)


Fair enough.

-- 
/Jacob Carlborg
Aug 28 2013
prev sibling parent "Kai Nacke" <kai redstar.de> writes:
On Wednesday, 28 August 2013 at 17:57:55 UTC, David Nadlinger 
wrote:

 I don't think this will be an extremely hard issue to solve, 
 but it depends on somebody actually spending some time on this 
 (and for myself, a 2.063-based release, Linux shared libraries, 
 and the Win32 wrong code bugs seem more important, given that 
 FreeBSD is a pretty niche OS…)


I committed a possible solution. Can someone please try it? Just 
pull the latest druntime commit.

Kai
Sep 02 2013