CoreCLR and OpenBSD

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

CoreCLR and OpenBSD

Aaron Bieber-2
Hi ports@,

For anyone interested in .NET running on OpenBSD, there is some action
over on
GitHub (https://github.com/dotnet/coreclr/issues/455) around *BSD
support.

Upstream has been very responsive in regards to merging in support for
BSD
systems and seems to have a strong desire to get it working on as many
OSs
as possible.

I would like to get coreclr to a state that would allow for a "drop in"
(no patches
needed) port.

If anyone else is interested in helping out, please ping me or offer
your services
on the issue listed above!

More info on CoreCLR is available in the main repo:
https://github.com/dotnet/coreclr/blob/master/Documentation/intro-to-clr.md

Cheers,
Aaron

Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

Aaron Bieber-2
Should have mentioned what the current hurdles are.  So far the build
dies because of a few lacking items:

1) libunwind (needed for the GC, also I am told this is not a hard
requirement)
2) lldb

I haven't had time to test the builds further to see if there is more
stuff needed.

----- Original message -----
From: Aaron Bieber <[hidden email]>
To: [hidden email]
Subject: CoreCLR and OpenBSD
Date: Thu, 19 Mar 2015 16:53:00 -0600

Hi ports@,

For anyone interested in .NET running on OpenBSD, there is some action
over on
GitHub (https://github.com/dotnet/coreclr/issues/455) around *BSD
support.

Upstream has been very responsive in regards to merging in support for
BSD
systems and seems to have a strong desire to get it working on as many
OSs
as possible.

I would like to get coreclr to a state that would allow for a "drop in"
(no patches
needed) port.

If anyone else is interested in helping out, please ping me or offer
your services
on the issue listed above!

More info on CoreCLR is available in the main repo:
https://github.com/dotnet/coreclr/blob/master/Documentation/intro-to-clr.md

Cheers,
Aaron

Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

sven falempin
On Thu, Mar 19, 2015 at 7:07 PM, Aaron Bieber <[hidden email]> wrote:
> Should have mentioned what the current hurdles are.  So far the build
> dies because of a few lacking items:
>
> 1) libunwind (needed for the GC, also I am told this is not a hard
> requirement)

libunwind depends on a libc extension called Setcontext, which i quote
wikipedia <is somewhat cumbersome to use effectively>, this libc
extension is present on NETBSD and FREEBSD but having this entering
into openBSD libc may take a long time, even bikeshed are taking time
here.

> 2) lldb
>
> I haven't had time to test the builds further to see if there is more
> stuff needed.
>
> ----- Original message -----
> From: Aaron Bieber <[hidden email]>
> To: [hidden email]
> Subject: CoreCLR and OpenBSD
> Date: Thu, 19 Mar 2015 16:53:00 -0600
>
> Hi ports@,
>
> For anyone interested in .NET running on OpenBSD, there is some action
> over on
> GitHub (https://github.com/dotnet/coreclr/issues/455) around *BSD
> support.
>
> Upstream has been very responsive in regards to merging in support for
> BSD
> systems and seems to have a strong desire to get it working on as many
> OSs
> as possible.
>
> I would like to get coreclr to a state that would allow for a "drop in"
> (no patches
> needed) port.
>
> If anyone else is interested in helping out, please ping me or offer
> your services
> on the issue listed above!
>
> More info on CoreCLR is available in the main repo:
> https://github.com/dotnet/coreclr/blob/master/Documentation/intro-to-clr.md
>
> Cheers,
> Aaron
>



--
---------------------------------------------------------------------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\

Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

Ted Unangst-6
sven falempin wrote:

> On Thu, Mar 19, 2015 at 7:07 PM, Aaron Bieber <[hidden email]> wrote:
> > Should have mentioned what the current hurdles are.  So far the build
> > dies because of a few lacking items:
> >
> > 1) libunwind (needed for the GC, also I am told this is not a hard
> > requirement)
>
> libunwind depends on a libc extension called Setcontext, which i quote
> wikipedia <is somewhat cumbersome to use effectively>, this libc
> extension is present on NETBSD and FREEBSD but having this entering
> into openBSD libc may take a long time, even bikeshed are taking time
> here.

setcontext was in posix, then they deleted it. we're unlikely to add very many
obsolete, already deleted functions to libc.

Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

Aaron Bieber-2
"Ted Unangst" <[hidden email]> writes:

> sven falempin wrote:
>> On Thu, Mar 19, 2015 at 7:07 PM, Aaron Bieber <[hidden email]> wrote:
>> > Should have mentioned what the current hurdles are.  So far the build
>> > dies because of a few lacking items:
>> >
>> > 1) libunwind (needed for the GC, also I am told this is not a hard
>> > requirement)
>>
>> libunwind depends on a libc extension called Setcontext, which i quote
>> wikipedia <is somewhat cumbersome to use effectively>, this libc
>> extension is present on NETBSD and FREEBSD but having this entering
>> into openBSD libc may take a long time, even bikeshed are taking time
>> here.
>
> setcontext was in posix, then they deleted it. we're unlikely to add very many
> obsolete, already deleted functions to libc.

Dmitrij, do you have any info on libunwind? I saw in ICB you had
mentioned upstream was making things work with c++03.

Sven, maybe #2 is a good place to start for now :D

Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

Stuart Henderson-6
In reply to this post by sven falempin
On 2015/03/19 22:16, sven falempin wrote:

> On Thu, Mar 19, 2015 at 7:07 PM, Aaron Bieber <[hidden email]> wrote:
> > Should have mentioned what the current hurdles are.  So far the build
> > dies because of a few lacking items:
> >
> > 1) libunwind (needed for the GC, also I am told this is not a hard
> > requirement)
>
> libunwind depends on a libc extension called Setcontext, which i quote
> wikipedia <is somewhat cumbersome to use effectively>, this libc
> extension is present on NETBSD and FREEBSD but having this entering
> into openBSD libc may take a long time, even bikeshed are taking time
> here.

This already came up a few times (PowerDNS recursor, MariaDB on some
arch), I don't think it was a bikeshed, the impression I got was that it
probably wouldn't go in even if someone sent a diff.

Most other programs wanting ucontext.h functions have some fallback code.

For unwind, there may possibly be something that could be borrowed
from boehm-gc...

Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

Amit Kulkarni-5
In reply to this post by Aaron Bieber-2
On Thu, Mar 19, 2015 at 6:07 PM, Aaron Bieber <[hidden email]> wrote:

> Should have mentioned what the current hurdles are.  So far the build
> dies because of a few lacking items:
>
> 1) libunwind (needed for the GC, also I am told this is not a hard
> requirement)
> 2) lldb
>

For lldb to be ported, the llvm/clang versions should be kept in sync. I
tried this a few years ago with matthew@, but we gave up since tehre were
too many ifdef with the POSIX string functions. I do believe that the
situation has improved a lot since then, since a ton of stuff has been
ported from FreeBSD/NetBSD. IMHO, a pre-requisite for porting lldb is to
sync the llvm port to the latest upstream release. I understand from
reading the commits that Brad has joined long term clang porting effort and
we have effectively forked llvm/clang to do our own stable long term
compiler as referenced by Miod a few years ago. IMHO a different port of
llvm/clang which follows latest upstream needs to be imported into the
tree. Is it time for the current llvm/clang port to be imported into base
but unlinked to the tree and make way for the latest llvm/clang port?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: CoreCLR and OpenBSD

Aaron Bieber-2


On Sat, Mar 28, 2015, at 12:52 PM, Amit Kulkarni wrote:

> On Thu, Mar 19, 2015 at 6:07 PM, Aaron Bieber <[hidden email]>
> wrote:
>
> > Should have mentioned what the current hurdles are.  So far the build
> > dies because of a few lacking items:
> >
> > 1) libunwind (needed for the GC, also I am told this is not a hard
> > requirement)
> > 2) lldb
> >
>
> For lldb to be ported, the llvm/clang versions should be kept in sync. I
> tried this a few years ago with matthew@, but we gave up since tehre were
> too many ifdef with the POSIX string functions. I do believe that the
> situation has improved a lot since then, since a ton of stuff has been
> ported from FreeBSD/NetBSD. IMHO, a pre-requisite for porting lldb is to
> sync the llvm port to the latest upstream release. I understand from
> reading the commits that Brad has joined long term clang porting effort
> and
> we have effectively forked llvm/clang to do our own stable long term
> compiler as referenced by Miod a few years ago. IMHO a different port of
> llvm/clang which follows latest upstream needs to be imported into the
> tree. Is it time for the current llvm/clang port to be imported into base
> but unlinked to the tree and make way for the latest llvm/clang port?
>
> Thanks

I am not too familiar with other things that require llvm/clang - but
for sure CoreCLR is currently targeting llvm/clang 3.5.

Reply | Threaded
Open this post in threaded view
|

LLVM (was: CoreCLR and OpenBSD)

Sebastien Marie
In reply to this post by Amit Kulkarni-5
On Sat, Mar 28, 2015 at 01:52:08PM -0500, Amit Kulkarni wrote:

> On Thu, Mar 19, 2015 at 6:07 PM, Aaron Bieber <[hidden email]> wrote:
>
> For lldb to be ported, the llvm/clang versions should be kept in sync. I
> tried this a few years ago with matthew@, but we gave up since tehre were
> too many ifdef with the POSIX string functions. I do believe that the
> situation has improved a lot since then, since a ton of stuff has been
> ported from FreeBSD/NetBSD. IMHO, a pre-requisite for porting lldb is to
> sync the llvm port to the latest upstream release. I understand from
> reading the commits that Brad has joined long term clang porting effort and
> we have effectively forked llvm/clang to do our own stable long term
> compiler as referenced by Miod a few years ago. IMHO a different port of
> llvm/clang which follows latest upstream needs to be imported into the
> tree. Is it time for the current llvm/clang port to be imported into base
> but unlinked to the tree and make way for the latest llvm/clang port?
>
> Thanks

As I am working to porting rustc to openbsd, it would help a lot to have
another updated llvm in ports.

Currently the port of rustc (see openbsd-wip/lang/rustc) start by
building llvm (using g++-4.8 as it need c++11) in order to build rustc.

I have try to build rustc with the current lang/llvm port, but
unsuccessfully.

Thanks.
--
Sébastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: LLVM (was: CoreCLR and OpenBSD)

Stuart Henderson-6
On 2015/04/05 09:55, Sébastien Marie wrote:
> Currently the port of rustc (see openbsd-wip/lang/rustc) start by
> building llvm (using g++-4.8 as it need c++11) in order to build rustc.

Does newer llvm require a c++11 standard library or is the older one
still usable? If at least the package can be made self-contained that
would be nice as it is pretty unappealing to pull in gcc 4.8/9 (as a
library dependency) when you pkg_add llvm.

Another possible issue is that depending on ports gcc during build is
that there will likely be a negative impact on bulk build time, llvm is
on the path to a number of large ports. Not sure how bad this will be.


Reply | Threaded
Open this post in threaded view
|

Re: LLVM (was: CoreCLR and OpenBSD)

Sebastien Marie
On Sun, Apr 05, 2015 at 09:56:34AM +0100, Stuart Henderson wrote:
> On 2015/04/05 09:55, Sébastien Marie wrote:
> > Currently the port of rustc (see openbsd-wip/lang/rustc) start by
> > building llvm (using g++-4.8 as it need c++11) in order to build rustc.
>
> Does newer llvm require a c++11 standard library or is the older one
> still usable?

I haven't tested a lot: my purpose was to package rustc, and not to
package llvm :)

What I have checked is that llvm complaint if building is done with base gcc:

| The selected GCC C++ compiler is not new enough to build LLVM. Please
| upgrade to GCC 4.7.

and if I force the use of base gcc, I have the following error:

| cc1plus: error: unrecognized command line option "-std=c++11"


next, if I try to build newer llvm with llvm from ports, the configure
have the following error:

| We detected a missing feature in the standard C++ library that was known
| to be missing in libstdc++4.6 and implemented in libstdc++4.7. There are
| numerous C++11 problems with 4.6's library, and we don't support GCCs or
| libstdc++ older than 4.7. You will need to update your system and ensure
| Clang uses the newer standard library.

same, if I bypass the check, build errors arrived very quickly...

| error: no template named 'enable_if' in namespace 'std'
| ...
| error: no type named 'remove_reference' in namespace 'std'
| ...
| error: 'Callable' does not refer to a value
| ...

But the errors could be due to us llvm version: the version annonced
(3.5) isn't exactly accurated: it is more something between 3.4 and 3.5
(if I recall the search I do when I have tried to build rustc with llvm
from ports).


> If at least the package can be made self-contained that
> would be nice as it is pretty unappealing to pull in gcc 4.8/9 (as a
> library dependency) when you pkg_add llvm.

I have just checked the binaries of llvm that are builded for rustc (but
aren't installed with using package: llvm is just a BUILD_DEP): all the
binaries builded depends of libestdc++.

So pkg_add llvm would install libstdc++-4.8.4p1 package (lang/gcc/4.8,-estdc).

But from build point of vue, yes building llvm would required to first
build lang/gcc.

> Another possible issue is that depending on ports gcc during build is
> that there will likely be a negative impact on bulk build time, llvm is
> on the path to a number of large ports. Not sure how bad this will be.

A test would be needed to measure the impact. Just add a BUILD_DEP for
gcc in llvm ports should be suffisant for measure it as first approch.

--
Sébastien Marie

Reply | Threaded
Open this post in threaded view
|

Re: LLVM (was: CoreCLR and OpenBSD)

Juan Francisco Cantero Hurtado
On Sun, Apr 05, 2015 at 02:27:16PM +0200, Sébastien Marie wrote:

> On Sun, Apr 05, 2015 at 09:56:34AM +0100, Stuart Henderson wrote:
> > On 2015/04/05 09:55, Sébastien Marie wrote:
> > > Currently the port of rustc (see openbsd-wip/lang/rustc) start by
> > > building llvm (using g++-4.8 as it need c++11) in order to build rustc.
> >
> > Does newer llvm require a c++11 standard library or is the older one
> > still usable?
>
> I haven't tested a lot: my purpose was to package rustc, and not to
> package llvm :)
>
> What I have checked is that llvm complaint if building is done with base gcc:
>
> | The selected GCC C++ compiler is not new enough to build LLVM. Please
> | upgrade to GCC 4.7.
>
> and if I force the use of base gcc, I have the following error:
>
> | cc1plus: error: unrecognized command line option "-std=c++11"
>
>
> next, if I try to build newer llvm with llvm from ports, the configure
> have the following error:
>
> | We detected a missing feature in the standard C++ library that was known
> | to be missing in libstdc++4.6 and implemented in libstdc++4.7. There are
> | numerous C++11 problems with 4.6's library, and we don't support GCCs or
> | libstdc++ older than 4.7. You will need to update your system and ensure
> | Clang uses the newer standard library.
>
> same, if I bypass the check, build errors arrived very quickly...
>
> | error: no template named 'enable_if' in namespace 'std'
> | ...
> | error: no type named 'remove_reference' in namespace 'std'
> | ...
> | error: 'Callable' does not refer to a value
> | ...

You're using clang + system libstdc++. Did you try with clang +
libestdc++?

>
> But the errors could be due to us llvm version: the version annonced
> (3.5) isn't exactly accurated: it is more something between 3.4 and 3.5
> (if I recall the search I do when I have tried to build rustc with llvm
> from ports).
>
>
> > If at least the package can be made self-contained that
> > would be nice as it is pretty unappealing to pull in gcc 4.8/9 (as a
> > library dependency) when you pkg_add llvm.
>
> I have just checked the binaries of llvm that are builded for rustc (but
> aren't installed with using package: llvm is just a BUILD_DEP): all the
> binaries builded depends of libestdc++.
>
> So pkg_add llvm would install libstdc++-4.8.4p1 package (lang/gcc/4.8,-estdc).
>
> But from build point of vue, yes building llvm would required to first
> build lang/gcc.
>
> > Another possible issue is that depending on ports gcc during build is
> > that there will likely be a negative impact on bulk build time, llvm is
> > on the path to a number of large ports. Not sure how bad this will be.
>
> A test would be needed to measure the impact. Just add a BUILD_DEP for
> gcc in llvm ports should be suffisant for measure it as first approch.
>
> --
> Sébastien Marie
>

--
Juan Francisco Cantero Hurtado http://juanfra.info