Added Area-VM, Triaged labels.

Removed Priority-Medium label.
Added Priority-Unassigned label.

This comment was originally written by beatg...@gmail.com

I got this error on a gclient runhooks:

________ running '/usr/local/bin/python dart/tools/gyp_dart.py runtime' in '/usr/home/otto'
gyp: Undefined variable dart_target_os in dart/runtime/dart-runtime.gyp while trying to load dart/runtime/dart-runtime.gyp
Error: Command /usr/local/bin/python dart/tools/gyp_dart.py runtime returned non-zero exit status 1 in /usr/home/otto

It looks like it's not set up to run on FreeBSD, but I don't know where to make changes (I don't know anything about gyp).

I searched for dart_target_os, and I found tools/gyp/configurations.gypi, which seemed like the place to add something in (configurations.gypi.patch, it's not very interesting). When I did this, I got the following error:

________ running '/usr/local/bin/python dart/tools/gyp_dart.py runtime' in '/usr/home/otto'
Traceback (most recent call last):
  File "dart/third_party/gyp/gyp_main.py", line 18, in <module>
    sys.exit(gyp.script_main())
  File "dart/third_party/gyp/pylib/gyp/init.py", line 547, in script_main
    return main(sys.argv[1:])
  File "dart/third_party/gyp/pylib/gyp/init.py", line 540, in main
    return gyp_main(args)
  File "dart/third_party/gyp/pylib/gyp/init.py", line 516, in gyp_main
    options.circular_check)
  File "dart/third_party/gyp/pylib/gyp/init.py", line 131, in Load
    params['parallel'])
  File "dart/third_party/gyp/pylib/gyp/input.py", line 2714, in Load
    SetUpConfigurations(target, target_dict)
  File "dart/third_party/gyp/pylib/gyp/input.py", line 2175, in SetUpConfigurations
    target_dict, configuration, [])
  File "dart/third_party/gyp/pylib/gyp/input.py", line 2116, in MergeConfigWithInheritance
    target_dict, parent, visited + [configuration])
  File "dart/third_party/gyp/pylib/gyp/input.py", line 2116, in MergeConfigWithInheritance
    target_dict, parent, visited + [configuration])
  File "dart/third_party/gyp/pylib/gyp/input.py", line 2111, in MergeConfigWithInheritance
    configuration_dict = target_dict['configurations'][configuration]
KeyError: 'Dart_FreeBSD_Base'
Error: Command /usr/local/bin/python dart/tools/gyp_dart.py runtime returned non-zero exit status 1 in /usr/home/otto

It looks like the string Dart_FreeBSD_Base is dynamically generated from dart_target_os, but I wasn't sure where to define it. I feel like I'm going down a deep rabbit hole that won't lead me to the solution. I'm sure it's easy, I just don't know where to look.

I don't know anything about gclient or gyp, and I didn't see any documentation in the repo to lead me in the right direction (except the README, which tells me I should be looking in tools/).

If I get time, I'll try to wrap my head around gyp and see if I can figure out where to go from here. Issue #6929 would make this much easier (something like chromium's source tarballs that Arch Linux uses).

Attachment:
configurations.gypi.patch (673 Bytes)

Regarding the patch in comment 4:

You might have a much easier time if you did say "[ 'OS=="freebsd"', { 'dart_target_os': 'Linux', } ]," as this will pickup all of the relevant build configurations for a make/gcc based build.

This comment was originally written by beatgam...@gmail.com

Making that change I get further. "glient sync", "gclient runhooks" and "tools/build.py -mrelease -ax64 runtime" (instructions from Issue #6929). Both returned 0 exit status, but there's no "out" directory in the dart directory.

All I get is: gmake: Nothing to be done for runtime

For reference, I'm using "glient config http://dart.google.com/svn/branches/1.1/deps/standalone.deps" (I figure that will be the easiest to get working). My build env is FreeBSD 9.2 with minimal software installed (e.g. no bash so I'm running gclient.py directly).

This comment was originally written by ef...@gmail.com

I gave up when building NSPR. Original Mozilla version has files for building with FreeBSD but in patched Dart branch are files somewhat missing. Even with proper files i am unable to compile it :(

This comment was originally written by sms3...@gmail.com

Has there been any update on this?

This comment was originally written by ets3rodama...@gmail.com

http://ugetdm.com/blog/3-stable/68-uget-for-bsd-is-now-available

Does that perhaps help?

This comment was originally written by @mulander

I started work on a port for OpenBSD (https://github.com/mulander/openbsd-dart).

Hacky at this point but I want to get at least the runtime built to see how the whole thing will feel. I'll start adding proper platform support for OpenBSD as soon as I get a single binary going (work limited to weekend so don't expect fast progress).

People wanting to help out are of course welcome.

This comment was originally written by sms3h...@gmail.com

Thanks for working on this! I'll try to jump in and help a little bit at
some point but the schedule is full!

This comment was originally written by @mulander

Hi all, short status update on the porting effort.

The build got pretty far, as in most of dart runtime builds without issues with small modifications to use kqueue/pthreads in some places - so far I 'patched' 36 files where most of them is 'use the mac one instead of linux' or 'use the android one instead of linux' with really rare cases when I actually had to edit the code. I obviously took the recommended "[ 'OS=="openbsd"', { 'dart_target_os': 'Linux', } ]," from comment #­5.

Unfortunately I'm also having huge issues with building NSPR similarly to what was reported in comment #­7 over an year ago. I'm afraid that without guidance/help I won't be able to move far with the port.

Regardless, it would be nice if the project had a porting guide for new platforms. I did not find any documentation that would tell me how the project build system works & how it should be configured. I don't know why the third party libs are bundled with the distribution & how to untangle them to use the system wide installed & already ported libraries. I assume the project has reasons for that but this leads to duplicate effort in software porting on the platform side.

The current state is of course uploaded to the github account linked in comment #­10.

We are working on moving the TLS support from Mozilla NSS to Boring SSL. If the NSS library and its dependencies are providing issues, then maybe just stubbing it out for now, and not support TLS until the change to use Boring SSL has landed.

This comment was originally written by @mulander

Hi sgjesse@, thanks for the response.

I will give stubbing out a shot over the next weekend, good to know that you are moving to Boring SSL.

Two little requests, please make it possible to pick up system wide Boring SSL during the build. Additionally I would be interested in using LibreSSL for dart on OpenBSD. Considering that both projects are an OpenSSL fork it should not be that hard if the build is not hard wired to Boring SSL.

Regards,
Adam

Hi guys, I'm @mulander from the migrated code.google.com comments (the guy trying to get Dart running on #OpenBSD).

I didn't give up and I'm really happy that BoringSSL replaced nss/nspr.

Though since the changes are only on head and adding OpenBSD support will be a much larger endeavour than just patching a file or two here & there I made a fork off the official repository and plan to do a proper port hopefully working with the upstream to make adding the BSD platform in a smooth way that's acceptable on both sides.

According to the Contributing guide I should give an up front notice with larger changes possibly coming down the line to coordinate.

Goals for my branch:

• build the base runtime on OpenBSD
• build the whole SDK
• allow using LibreSSL instead of BoringSSL
• eventually build the Dartium browser

There's no action that upstream needs to take now of course. The initial porting effort with an updated status can be found here, the new fork is under my account here.

cc @whesse and @mit-mit

Have you considered trying to make the ninja build work, rather than the make build? It may be that this new build system is more rational, and the generation of the build files by gyp is clearer, than the "make" gyp_generator. Documentation for gyp is at https://chromium.googlesource.com/external/gyp/+/md-pages/index.md

@whesse I didn't try the ninja build. Essentially I got this one working flawlessly by putting symlinks to gcc, g++ & cc in a local directory that is in front of $PATH.

I would personally say the build feels to be going quite well so far and I think I'm not that far away from having a working runtime. Though the porting effort is paused until the next weekend.

@mulander any update on your effort? I would really love to see DartVM on the BSD's (FreeBSD in particular) ... and I would like to help .. just don't think I have the needed skills.

@pbgc I was able to last work on this port on September 19th. Unfortunately since then work has been busy which left no time for further dart work. I did not abandon the porting effort - it's just on hold for now.

Initial porting effort: https://github.com/mulander/openbsd-dart
Normal branch to work on upstreaming proper support: https://github.com/mulander/sdk/commits/OpenBSD-support

@krytarowski started a similar effort to port Dart to NetBSD based on my current status, his repository is here: https://github.com/krytarowski/sdk (also on hold from what I know)

@pbgc though it should be noted I am porting this for OpenBSD not FreeBSD though as you might be aware the work should be really similar (same with NetBSD as we found out). You can start by forking the dart repository and adding *_freebsd.cc/h files based on the ones I added in my repository. That should get you pretty far building the code on FreeBSD.

and I would like to help .. just don't think I have the needed skills.

It just needs time. I'm also not the best person to do this but look at the age of this ticket. If people like me and you don't attempt it then we can wait another 3 years without anyone else picking the issue up. I will gladly help you get to the same spot on FreeBSD that I am with OpenBSD. Feel free to ask me question or just grab query with me on IRC @ freenode nick mulander.

@mulander Thanks! I decided that trying to accomplish this will be one of my new year resolutions. On January I will setup my machine to be able to build and then will start. I will then contact you on freenode (nick pbgc)

Hi!
A quick status update!
I was able to build the runtime on FreeBSD by patching 25 files (using linux plataform as base with some files from macos), including several gyp files.
I will now try to build all the sdk and then make a proper Platform for FreeBSD and will try to coordinate my effort with @mulander so we can have FreeBSD and OpenBSD (NetBSD will be also easy).
Currently I have 10/3785 failed tests:

= 10 tests failed

[08:16 | 100% | + 3775 | - 10]

--- Total time: 08:16 ---
0:05:06.454286 - vm - none-vm-checked release_x64/language/factory_redirection_test/04
0:05:06.440066 - vm - none-vm-checked release_x64/language/factory_redirection_test/05
0:05:06.435563 - vm - none-vm-checked release_x64/language/factory_redirection_test/06
0:05:06.430600 - vm - none-vm-checked release_x64/language/factory_redirection_test/07
0:03:23.218128 - vm - none-vm-checked release_x64/language/large_class_declaration_test
0:02:43.406611 - vm - none-vm-checked release_x64/language/async_await_syntax_test/b11d
0:02:37.621098 - vm - none-vm-checked release_x64/language/async_await_test/03
0:02:37.266058 - vm - none-vm-checked release_x64/language/async_await_test/02
0:02:14.180701 - vm - none-vm-checked release_x64/language/classes_static_method_clash_test
0:01:15.562117 - vm - none-vm-checked release_x64/language/closure_cycles_test
0:00:41.783698 - vm - none-vm-checked release_x64/language/gc_test
0:00:35.128110 - vm - none-vm-checked release_x64/language/hello_dart_test
0:00:27.538508 - vm - none-vm-checked release_x64/language/factory_redirection_test/08
0:00:25.880236 - vm - none-vm-checked release_x64/language/async_await_test/none
0:00:21.531277 - vm - none-vm-checked release_x64/language/ct_const2_test
0:00:19.084653 - vm - none-vm-checked release_x64/language/await_for_test
0:00:18.226716 - vm - none-vm-checked release_x64/language/disassemble_test
0:00:10.358696 - vm - none-vm-checked release_x64/language/vm/debug_break_enabled_vm_test/01
0:00:09.750202 - vm - none-vm-checked release_x64/language/async_await_syntax_test/b13a
0:00:09.183596 - vm - none-vm-checked release_x64/language/vm/optimized_stacktrace_test

I don't know if the tests are failing because of the port ... or because of the PRE-1.14 status of the rep.

pbeck@dart:~/dart/sdk % ./out/ReleaseX64/dart --version
Dart VM version: 1.14.0-edge.6602644bb3fd094cddc638a8e963c6a49d9cbdc8 (Tue Dec 29 08:46:27 2015) on "linux_x64"

pbeck@dart:~/dart/sdk % uname -a
FreeBSD dart 10.2-RELEASE-p7 FreeBSD 10.2-RELEASE-p7 #0: Mon Nov 2 14:19:39 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

Running the tests with:

./out/ReleaseX64/dart tools/test.dart --compiler none --runtime vm --progress color --arch x64 --mode release --checked --report --time --tasks 6 -t60 language

I get 8 tests failed

[08:20 | 100% | + 3777 | - 8]

--- Total time: 08:20 ---
0:07:56.502934 - vm - none-vm-checked release_x64/language/async_await_syntax_test/a15c
0:07:56.375965 - vm - none-vm-checked release_x64/language/async_await_syntax_test/a15d
0:06:03.708446 - vm - none-vm-checked release_x64/language/ct_const2_test
0:05:48.473868 - vm - none-vm-checked release_x64/language/disassemble_test
0:03:23.058061 - vm - none-vm-checked release_x64/language/large_class_declaration_test
0:02:21.911094 - vm - none-vm-checked release_x64/language/async_await_syntax_test/b00a
0:01:34.449744 - vm - none-vm-checked release_x64/language/classes_static_method_clash_test
0:01:17.627236 - vm - none-vm-checked release_x64/language/closure_cycles_test
0:00:42.253910 - vm - none-vm-checked release_x64/language/gc_test
0:00:37.057008 - vm - none-vm-checked release_x64/language/vm/optimized_stacktrace_test
0:00:36.798708 - vm - none-vm-checked release_x64/language/hello_dart_test
0:00:26.233428 - vm - none-vm-checked release_x64/language/async_await_test/none
0:00:19.042199 - vm - none-vm-checked release_x64/language/await_for_test
0:00:14.891542 - vm - none-vm-checked release_x64/language/async_await_syntax_test/b00c
0:00:11.004358 - vm - none-vm-checked release_x64/language/vm/debug_break_enabled_vm_test/01
0:00:09.445221 - vm - none-vm-checked release_x64/language/async_await_syntax_test/e1
0:00:07.805136 - vm - none-vm-checked release_x64/language/async_star_test
0:00:06.947421 - vm - none-vm-checked release_x64/language/vm/closure_memory_retention_test
0:00:04.021573 - vm - none-vm-checked release_x64/language/inferrer_constructor5_test/none
0:00:02.996990 - vm - none-vm-checked release_x64/language/allocate_test

Executing a test in isolation I get this information:

Total: 3788 tests

• 3 tests will be skipped (0 skipped by design)
• 0 tests are expected to be flaky but not crash
• 0 tests are expected to flaky crash
• 3746 tests are expected to pass
• 22 tests are expected to fail that we won't fix
• 15 tests are expected to fail that we should fix
• 0 tests are expected to crash that we should fix
• 0 tests are allowed to timeout
• 0 tests are skipped on browsers due to compile-time error
• 2 could not be categorized or are in multiple categories

So ... I'm confused .....

Can someone give me some guidance on what to look for (thread implementation, etc..) if any of the failed tests are unexpected failures?

I forgot to mention ... The build is done with CLANG:

pbeck@dart:~/dart/sdk % clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix

Thanks in advance!
Pedro Costa

Please upstream BSD bits as soon as possible, I will mirror them for NetBSD.

It's been 3 months since the pull request and over 2 months since last update.

Are there any plans regarding supporting BSD as a platform that can be shared with the general public? I'm still interested in helping & supporting an OpenBSD port of the Dart language.

Ping, we are still alive.

So should this issue just be closed? I see no point in lying to anyone else that something will be done here.

@mulander, I'm still a believer.

@krytarowski , @mulander , sincere apologies for taking so long and thanks @Zectbumo for still being a believer... We talked about this and came up with a proposal that might help us get support for OpenBSD landed while addressing some of the raised concerns.

If we could change the CL to move files specific to these additional ports into runtime/third-party/ that would help make the distinction clearer and maintenance easier, e.g. rather than having the files “atomic_openbsd.h”, “cpuinfo_openbsd.cc”, and “debuginfo_openbsd.cc” in “runtime/vm” we would have them in “runtime/third_party/vm”. Similarly, files such as “socket_openbsd.h” and “socket_openbsd.cc” would be moved from “runtime/bin” to “runtime/third_party/bin”.

what does 3rd party mean in your definition?

@a-siva what CL? This one? https://codereview.chromium.org/1559053002/ created 4 months, 4 weeks ago that has merge conflicts and by now should be redone from scratch as upstream continued development while the code stalled?

@iposva-google said 3 months ago that one of the stalls was:

Thirdly, we have learned that there is more commonality between related OS platforms than initially meets the eye at least when working in the Dart VM code base. The split between Linux and Android was mentioned here and we have come to the conclusion that it was a mistake.

Is moving the .*_openbsd files to third_party a solution to this? Seriously?

The other reason for stalling was running a build bot. Apparently it was so important that no one since January replied to my offer of self hosting a build bot for the platform.

We talked about this and came up with a proposal that might help us get support for OpenBSD landed while addressing some of the raised concerns.

I'm happy that you talked. It's quite sad that not all of the interested parties were invited to the table.

@mulander I understand your frustration at the delay in getting this in. I am trying to move this issue forward and get a resolution. It is possible that moving the files to third_party is not ideal but it does provide us a clean separation of the hosts that the Dart team ships periodically as install ready binaries in a SDK vs other hosts. If you have other ideas on how we can maintain this separation I am willing to listen.

I understand the comment earlier from @iposva-google about the possibility of refactoring the OS specific files to share code but as indicated in that comment we request that you start with a bsd version and look at refactoring later.

@krytarowski by third party I meant the hosts that are not actively shipped by the Dart team as install ready binaries in a SDK.

@a-siva, I have some suggestions on maintaining clear separation between the hosts that the Dart team ships periodically and ones that are supported by the community:

• Add the separation via the build system so that the build step that you use to build the install ready binaries does not by default build binaries for non-supported hosts.
• Keep the files ending with _openbsd.cc and _openbsd.h in the source directory (if you don't want to see the OpenBSD files in the bin/runtime directory for whatever reason, consider moving the host specific files into a single separate directory for host-specific code or to multiple separate directories based on what is being specialized for each host).
• Add disclaimers on each of the files that are specific to non-supported hosts explaining that these hosts are not being supported directly by Google and that the Dart SDK is only available on these hosts because of generous contributions from people from the community who spent their limited time porting the Dart SDK to a new host so that they could enable the usage of the Dart SDK on that host for the benevolence of the Dart community.

@iposva-google I also think it's unreasonable ask @mulander to add support for all of the BSD operating systems in one set of files ending in _bsd.cc and_bsd.hh as @mulander would have to then add support for at least two different operating systems which is quite extreme (show some empathy and think about the human cost (in terms of time and effort) that would be required to learn about all the different BSD operating systems and then validating and testing the code on a few of the major BSD operating systems just to get the work that was already done for OpenBSD merged upstream).

I started the FreeBSD port 1 year ago ... and was able (like I commented here above) to build and pass most of the tests.
I had plans to make a proper port (with separate files and not patches on the linux ones) but after seeing how the Dart team treated the BSD ports efforts and specially Mulander's work ... I really got disappointed and lost all interest in Dart!
I've abandoned (a long time ago) the port effort and don't even use Dart anymore and will stop watching this rep.

@pbgc Well maybe this is anti-competitive behavior in the open source space (in terms of operating systems) by Google who happens to be one of the largest (if not largest) Linux vendor (via Android and Chrome OS) and Linux user (via their web services and Google Cloud Platform). It might be possible that the Dart developers may have been disallowed (as part of a larger strategy by upper management) from bringing support for any open source non-Linux/non-Google-developed operating system into the mainline of the Dart SDK.

Maybe this suggestion is silly, but I really have a hard time believing the argument that allowing the Dart open source community to support other operating systems puts a burden on the developers of Dart that outweighs the benefits (for Dart programmers) of being able to use the Dart SDK on other operating systems.

Dart won't take me switch from NetBSD to Linux.

I know its very distant goal from having a native BSD port but has anyone tried running Dart Linux binaries in FreeBSD using Linux Binary Compatibility[1]? Maybe formal support for FreeBsd LBC would be a good start?

1. https://www.freebsd.org/doc/handbook/linuxemu.html

OpenBSD dropped Linux compatibility a couple releases ago.

Any chance of a FreeBSD port?

@pbgc I've likewise abandoned Dart because I see nothing in the Dart project to give me confidence that it will be ported. I'm willing to give it another look if things change, but I can't use something if it doesn't support the systems I deploy on.

As such, I've moved my focus to other platforms that do have support for *BSD. I understand that the team may have different priorities, and I also understand that the majority of their customer base likely wouldn't benefit directly from *BSD support.

This may have changed in the past, but getting set up to even work on this was a daunting task since it was (again, not sure if this has changed) part of the monolithic Chromium source tree. As such, I put some effort into porting (about a day of work), but it was such a huge barrier to entry that I lost interest and moved on to other projects.

It does not seem like we have any immediate plans to support FreeBSD

It is awful.

I realize this is a very passionate issue for FreeBSD users, but the issue here is we don't have the resources to do this ourselves, and have little need for it (the VM is currently focusing on deploying to mobile devices for Flutter, for example).

It's fine to be disappointed, but please be respectful.