New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

help build oc on FreeBSD #338

Closed
mexas opened this Issue Feb 18, 2017 · 22 comments

Comments

3 participants
@mexas

mexas commented Feb 18, 2017

I'm trying to make a port of opencoarrays on FreeBSD.
I need your help.

The FreeBSD ports system is a very tightly integrated collection
of makefiles, one for each port. All prerequisites of opencoarrays
are already provided in their respective ports, so it makes no sense
running install.sh. Instead I'm trying to make the main opencoarrays
Makefile to invoke either cmake or make. BTW, it seems you makefile
uses lots of gmake extensions, which are not supported by BSD make.

Anyway:

root@rat:/usr/ports/lang/OpenCoarrays/work/OpenCoarrays-1.8.4/src # gmake
gmake -C common
gmake[1]: Entering directory '/usr/ports/lang/OpenCoarrays/work/OpenCoarrays-1.8.4/src/common'
gcc -I.. -O2 -g -DPREFIX_NAME=gfortran_caf -DHAVE_INT128_T -c caf_auxiliary.c -o caf_auxiliary.o
gmake[1]: Leaving directory '/usr/ports/lang/OpenCoarrays/work/OpenCoarrays-1.8.4/src/common'
gmake -C mpi
gmake[1]: Entering directory '/usr/ports/lang/OpenCoarrays/work/OpenCoarrays-1.8.4/src/mpi'
mpicc -O2 -g -DPREFIX_NAME=gfortran_caf -DHAVE_INT128_T -DSTRIDED -DSTRIDED -I.. -c mpi_caf.c -o mpi_caf.o
mpi_caf.c:40:10: fatal error: 'alloca.h' file not found
#include <alloca.h>
^
1 error generated.

mpicc is built on top of LLVM:

mpicc --version

FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)

Do I need mpicc built with gcc?

Thanks

Anton

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Feb 18, 2017

ok, got it. On FreeBSD alloca is in stdlib.h.
I also rebuilt mpich with gcc6.
Will try again.
Anton

mexas commented Feb 18, 2017

ok, got it. On FreeBSD alloca is in stdlib.h.
I also rebuilt mpich with gcc6.
Will try again.
Anton

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Feb 18, 2017

yes, this works.
With cmake I get everything

35/35 Test #35: test-installation-scripts.sh .....   Passed    0.21 sec

100% tests passed, 0 tests failed out of 35

Total Test time (real) =  11.08 sec

So I'll go ahead and make a port based
on cmake.

mexas commented Feb 18, 2017

yes, this works.
With cmake I get everything

35/35 Test #35: test-installation-scripts.sh .....   Passed    0.21 sec

100% tests passed, 0 tests failed out of 35

Total Test time (real) =  11.08 sec

So I'll go ahead and make a port based
on cmake.

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Feb 18, 2017

Member

If you can install CMake, I would recommend reading the comment I just posted on the other issue, and reading about "advanced" CMake install in INSTALL.md

Member

zbeekman commented Feb 18, 2017

If you can install CMake, I would recommend reading the comment I just posted on the other issue, and reading about "advanced" CMake install in INSTALL.md

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Feb 21, 2017

cmake is not a problem.
I now got to FreeBSD QA, which refuse to install caf or cafrun:

====> Running Q/A tests (stage-qa)
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/caf'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/cafrun'

This shebang is not portable.
Please update to

#!/usr/bin/env bash

as in your

install.sh

Thanks

Anton

mexas commented Feb 21, 2017

cmake is not a problem.
I now got to FreeBSD QA, which refuse to install caf or cafrun:

====> Running Q/A tests (stage-qa)
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/caf'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/cafrun'

This shebang is not portable.
Please update to

#!/usr/bin/env bash

as in your

install.sh

Thanks

Anton

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Feb 21, 2017

Also, which oc files absolutely must be installed for oc to be usable?
I got:

caf
cafrun
libcaf_mpi.a

Do I also need to install

opencoarrays.mod

Anything else?

Thanks

Anton

mexas commented Feb 21, 2017

Also, which oc files absolutely must be installed for oc to be usable?
I got:

caf
cafrun
libcaf_mpi.a

Do I also need to install

opencoarrays.mod

Anything else?

Thanks

Anton

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Feb 21, 2017

Another issue.
cafrun has

CAFRUN=/usr/local/usr/bin/env mpiexec

which doesn't make sense.
Although the tests run fine, when I try to
run a simple test program outside of the build
environment, I get

/usr/local/bin/cafrun: line 84: : command not found

where line 84 is

  "${CAFRUN}" "$@"

If I change CAFRUN e.g. to

CAFRUN=/usr/local/bin/mpiexec

then all is fine.

Please advise

Thanks

Anton

mexas commented Feb 21, 2017

Another issue.
cafrun has

CAFRUN=/usr/local/usr/bin/env mpiexec

which doesn't make sense.
Although the tests run fine, when I try to
run a simple test program outside of the build
environment, I get

/usr/local/bin/cafrun: line 84: : command not found

where line 84 is

  "${CAFRUN}" "$@"

If I change CAFRUN e.g. to

CAFRUN=/usr/local/bin/mpiexec

then all is fine.

Please advise

Thanks

Anton

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Feb 21, 2017

Member

Also, which oc files absolutely must be installed for oc to be usable?
I got:

caf
cafrun
libcaf_mpi.a

These are the bare minimum

Do I also need to install

opencoarrays.mod

This is a user extension that let's you call the collectives with old versions of gfortran etc. Please keep in mind, if making a package for FreeBSD, you need a very recent GFortran, the newer, the better, preferably >= 6.1 (with 5.4 as a bare minimum).

Anything else?

You can tell cmake to build shared libs... but if you don't do that, then you don't need to worry about it.

Member

zbeekman commented Feb 21, 2017

Also, which oc files absolutely must be installed for oc to be usable?
I got:

caf
cafrun
libcaf_mpi.a

These are the bare minimum

Do I also need to install

opencoarrays.mod

This is a user extension that let's you call the collectives with old versions of gfortran etc. Please keep in mind, if making a package for FreeBSD, you need a very recent GFortran, the newer, the better, preferably >= 6.1 (with 5.4 as a bare minimum).

Anything else?

You can tell cmake to build shared libs... but if you don't do that, then you don't need to worry about it.

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Feb 21, 2017

Member

I now got to FreeBSD QA, which refuse to install caf or cafrun:

====> Running Q/A tests (stage-qa)
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/caf'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/cafrun'
This shebang is not portable.
Please update to

#!/usr/bin/env bash
as in your

install.sh

Yes the wrapper scripts have some work left to be done on them. (e.g. #268) I'll submit a quick PR to fix this issue.

Another issue.
cafrun has

CAFRUN=/usr/local/usr/bin/env mpiexec
which doesn't make sense.
Although the tests run fine, when I try to
run a simple test program outside of the build
environment, I get

/usr/local/bin/cafrun: line 84: : command not found
where line 84 is

"${CAFRUN}" "$@"
If I change CAFRUN e.g. to

CAFRUN=/usr/local/bin/mpiexec
then all is fine.

Please advise

Yes I'm not sure how this happened but this should be fixed as well. I'll include it in the PR.

Member

zbeekman commented Feb 21, 2017

I now got to FreeBSD QA, which refuse to install caf or cafrun:

====> Running Q/A tests (stage-qa)
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/caf'
Error: '/bin/bash' is an invalid shebang you need USES=shebangfix for 'bin/cafrun'
This shebang is not portable.
Please update to

#!/usr/bin/env bash
as in your

install.sh

Yes the wrapper scripts have some work left to be done on them. (e.g. #268) I'll submit a quick PR to fix this issue.

Another issue.
cafrun has

CAFRUN=/usr/local/usr/bin/env mpiexec
which doesn't make sense.
Although the tests run fine, when I try to
run a simple test program outside of the build
environment, I get

/usr/local/bin/cafrun: line 84: : command not found
where line 84 is

"${CAFRUN}" "$@"
If I change CAFRUN e.g. to

CAFRUN=/usr/local/bin/mpiexec
then all is fine.

Please advise

Yes I'm not sure how this happened but this should be fixed as well. I'll include it in the PR.

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Feb 22, 2017

Also, users might want to build with OpenMPI instead of MPICH.
On FreeBSD multiple MPI installations can coexist at different paths, e.g.
OpenMPI is installed by default under

/usr/local/mpi/openmpi2/bin

What do I need to change in OC scripts to use the MPI library
from that path?

Thanks

Anton

mexas commented Feb 22, 2017

Also, users might want to build with OpenMPI instead of MPICH.
On FreeBSD multiple MPI installations can coexist at different paths, e.g.
OpenMPI is installed by default under

/usr/local/mpi/openmpi2/bin

What do I need to change in OC scripts to use the MPI library
from that path?

Thanks

Anton

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Feb 22, 2017

Member

CMake handles MPI via FindMPI. It should automagically pick up whichever MPI is activated. If you're using gnu environment modules just unload mpich and load mpi before invoking CMake. Otherwise, FindMPI usually looks for MPI wrappers etc. on your PATH. It will also check the environment variable MPI_HOME. If all else fails, you can try passing -DMPI_C_COMPILER:PATH=/path/to/C/compiler/wrapper/script and -DMPI_Fortran_COMPILER:PATH=/path/to/Fortran/compiler/wrapper/script or worst case scenario, tell CMake where the libraries and headers etc. are. See https://cmake.org/cmake/help/v3.7/module/FindMPI.html#usage

Member

zbeekman commented Feb 22, 2017

CMake handles MPI via FindMPI. It should automagically pick up whichever MPI is activated. If you're using gnu environment modules just unload mpich and load mpi before invoking CMake. Otherwise, FindMPI usually looks for MPI wrappers etc. on your PATH. It will also check the environment variable MPI_HOME. If all else fails, you can try passing -DMPI_C_COMPILER:PATH=/path/to/C/compiler/wrapper/script and -DMPI_Fortran_COMPILER:PATH=/path/to/Fortran/compiler/wrapper/script or worst case scenario, tell CMake where the libraries and headers etc. are. See https://cmake.org/cmake/help/v3.7/module/FindMPI.html#usage

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Mar 6, 2017

ok, the port work is progressing.
Several issues have come up.
Do let me know if you prefer me to open separate PRs for these.

A symbolic link is created inside DESTDIR (stage directory) instead of /usr/local.
The patch also makes the link relative instead of absolute.
I think you might want to update this:

--- src/mpi/CMakeLists.txt.orig 2017-02-07 05:19:01 UTC
+++ src/mpi/CMakeLists.txt
@@ -58,15 +58,15 @@ install(TARGETS caf_mpi EXPORT OpenCoarr
 )

 # Install modules to standard include dir, but namespace them with compiler/version
-set (mod_install "${CMAKE_INSTALL_FULL_INCLUDEDIR}/OpenCoarrays/${CMAKE_Fortran_COMPILER_ID}/${CMAKE_Fortran_COMPILER_VERSION}")
+set (mod_install "OpenCoarrays/${CMAKE_Fortran_COMPILER_ID}/${CMAKE_Fortran_COMPILER_VERSION}")
 install(DIRECTORY  "${CMAKE_BINARY_DIR}/mod/"
-  DESTINATION "${mod_install}"
+  DESTINATION "${CMAKE_INSTALL_FULL_INCLUDEDIR}/${mod_install}"
   FILES_MATCHING PATTERN "*.mod"
 )

 # Now add a link in standard include dir so that compilers will find by default... this may or may
 not actually be a good idea...
 if ( "${CMAKE_Fortran_COMPILER_ID}" MATCHES "GNU" )
-  INSTALL(CODE "execute_process( COMMAND ${CMAKE_COMMAND} -E create_symlink ${mod_install}/opencoarrays.mod ${CMAKE_INSTALL_FULL_INCLUDEDIR}/opencoarrays.mod )"
+  INSTALL(CODE "execute_process( COMMAND ${CMAKE_COMMAND} -E create_symlink ${mod_install}/opencoarrays.mod \$ENV{DESTDIR}${CMAKE_INSTALL_FULL_INCLUDEDIR}/opencoarrays.mod )"
   )
 endif ()

Anton

mexas commented Mar 6, 2017

ok, the port work is progressing.
Several issues have come up.
Do let me know if you prefer me to open separate PRs for these.

A symbolic link is created inside DESTDIR (stage directory) instead of /usr/local.
The patch also makes the link relative instead of absolute.
I think you might want to update this:

--- src/mpi/CMakeLists.txt.orig 2017-02-07 05:19:01 UTC
+++ src/mpi/CMakeLists.txt
@@ -58,15 +58,15 @@ install(TARGETS caf_mpi EXPORT OpenCoarr
 )

 # Install modules to standard include dir, but namespace them with compiler/version
-set (mod_install "${CMAKE_INSTALL_FULL_INCLUDEDIR}/OpenCoarrays/${CMAKE_Fortran_COMPILER_ID}/${CMAKE_Fortran_COMPILER_VERSION}")
+set (mod_install "OpenCoarrays/${CMAKE_Fortran_COMPILER_ID}/${CMAKE_Fortran_COMPILER_VERSION}")
 install(DIRECTORY  "${CMAKE_BINARY_DIR}/mod/"
-  DESTINATION "${mod_install}"
+  DESTINATION "${CMAKE_INSTALL_FULL_INCLUDEDIR}/${mod_install}"
   FILES_MATCHING PATTERN "*.mod"
 )

 # Now add a link in standard include dir so that compilers will find by default... this may or may
 not actually be a good idea...
 if ( "${CMAKE_Fortran_COMPILER_ID}" MATCHES "GNU" )
-  INSTALL(CODE "execute_process( COMMAND ${CMAKE_COMMAND} -E create_symlink ${mod_install}/opencoarrays.mod ${CMAKE_INSTALL_FULL_INCLUDEDIR}/opencoarrays.mod )"
+  INSTALL(CODE "execute_process( COMMAND ${CMAKE_COMMAND} -E create_symlink ${mod_install}/opencoarrays.mod \$ENV{DESTDIR}${CMAKE_INSTALL_FULL_INCLUDEDIR}/opencoarrays.mod )"
   )
 endif ()

Anton

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Mar 6, 2017

We can now build OC with mpich-3.2_3, openmpi-1.10.6 and openmpi2-2.0.2_2.
However, only mpich passes tests, and not all of them.
The full logs:

  1. mpich: http://eis.bris.ac.uk/~mexas/oca-mpich.log
  2. openmpi: http://eis.bris.ac.uk/~mexas/oca-openmpi.log
  3. openmpi2: http://eis.bris.ac.uk/~mexas/oca-openmpi2.log

Anything obvious?
I wonder if there are some linux assumptions in the tests which are not
true on FreeBSD?

Anton

mexas commented Mar 6, 2017

We can now build OC with mpich-3.2_3, openmpi-1.10.6 and openmpi2-2.0.2_2.
However, only mpich passes tests, and not all of them.
The full logs:

  1. mpich: http://eis.bris.ac.uk/~mexas/oca-mpich.log
  2. openmpi: http://eis.bris.ac.uk/~mexas/oca-openmpi.log
  3. openmpi2: http://eis.bris.ac.uk/~mexas/oca-openmpi2.log

Anything obvious?
I wonder if there are some linux assumptions in the tests which are not
true on FreeBSD?

Anton

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Mar 6, 2017

Member

Hi Anton,

First of all apologies that I haven't gotten around to looking at this in more detail and addressing #268 to fix some of your portability issues....

Can you please remind me which version of GCC/GFortran you're using, as well as which version of OpenCoarrays?

As for tests not passing, there may be an issue related to #267 where we're limiting the number of cores for OpenMPI in a bad way, where the test requires a minimum number but we're detecting a limited number of physical cores and being overly-restrictive in our anti-oversubscribing paradigm for OpenMPI. It's also possible that the resolution #265 might mean that OpenMPI now works fine even when oversubscribed... I'll have to do some testing and look through your logs.

Member

zbeekman commented Mar 6, 2017

Hi Anton,

First of all apologies that I haven't gotten around to looking at this in more detail and addressing #268 to fix some of your portability issues....

Can you please remind me which version of GCC/GFortran you're using, as well as which version of OpenCoarrays?

As for tests not passing, there may be an issue related to #267 where we're limiting the number of cores for OpenMPI in a bad way, where the test requires a minimum number but we're detecting a limited number of physical cores and being overly-restrictive in our anti-oversubscribing paradigm for OpenMPI. It's also possible that the resolution #265 might mean that OpenMPI now works fine even when oversubscribed... I'll have to do some testing and look through your logs.

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Mar 6, 2017

I use GCC 6.3.1 and OpenCoarrays 1.8.4.
I could try also GCC 7.0.0.s20170101, if you think it's helpful.

I'll try to test opencoarrays built with openmpi manually, outside
of the supplied tests.

mexas commented Mar 6, 2017

I use GCC 6.3.1 and OpenCoarrays 1.8.4.
I could try also GCC 7.0.0.s20170101, if you think it's helpful.

I'll try to test opencoarrays built with openmpi manually, outside
of the supplied tests.

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Mar 13, 2017

The port is now live:
http://www.freshports.org/lang/opencoarrays
https://www.freebsd.org/cgi/ports.cgi?query=opencoarrays

I think it's great positive publicity for OpenCoarrays project,
as FreeBSD is a major BSD licensed free OS, a long term
linux alternative. I think this port deserves a mention in OpenCoarrays
news.

Please close this PR.

Thanks

Anton

mexas commented Mar 13, 2017

The port is now live:
http://www.freshports.org/lang/opencoarrays
https://www.freebsd.org/cgi/ports.cgi?query=opencoarrays

I think it's great positive publicity for OpenCoarrays project,
as FreeBSD is a major BSD licensed free OS, a long term
linux alternative. I think this port deserves a mention in OpenCoarrays
news.

Please close this PR.

Thanks

Anton

@rouson

This comment has been minimized.

Show comment
Hide comment
@rouson

rouson Mar 14, 2017

Member

Thanks, @mexas. How will these ports get updated as we produce new releases? Are you listed somewhere as the maintainer? Do we need to let you know each time we release? We usually announce releases via the OpenCoarrays Google Group.

Member

rouson commented Mar 14, 2017

Thanks, @mexas. How will these ports get updated as we produce new releases? Are you listed somewhere as the maintainer? Do we need to let you know each time we release? We usually announce releases via the OpenCoarrays Google Group.

@rouson rouson self-assigned this Mar 14, 2017

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Mar 14, 2017

Member

FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)

Do I need mpicc built with gcc?

Just FYI, on Mac OS OpenMPI and MPICH are build with clang/LLVM by default, and I usually have no trouble running OpenCoarrays with the homebrew (Clang/LLVM) MPI binary packages, as well as building them from source with both GCC and Clang/LLVM. Since C is ABI stable/compatible across compilers you should be able to call MPI libraries built with any C compiler from a different C compiler. Since the OpenCoarrays library is written in C this means it shouldn't matter which compiler MPI was built with, and you can even use LLVM/Clang as the C compiler for building OpenCoarrays on Mac OS.

Member

zbeekman commented Mar 14, 2017

FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0)

Do I need mpicc built with gcc?

Just FYI, on Mac OS OpenMPI and MPICH are build with clang/LLVM by default, and I usually have no trouble running OpenCoarrays with the homebrew (Clang/LLVM) MPI binary packages, as well as building them from source with both GCC and Clang/LLVM. Since C is ABI stable/compatible across compilers you should be able to call MPI libraries built with any C compiler from a different C compiler. Since the OpenCoarrays library is written in C this means it shouldn't matter which compiler MPI was built with, and you can even use LLVM/Clang as the C compiler for building OpenCoarrays on Mac OS.

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Mar 14, 2017

Damian, I'm listed as the maintainer on both links above.
If I find it's too much for me I'll pass it on
to ports@freebsd.org unless somebody else will be willing to take it up.
I think for standard repositories and standard paths, like yours, the
FreeBSD portscluster should pick it up automatically when an update
is available. Otherwise it's one of the port maintainers duties to track
the development of the code and update the port if and when required.
I'll try to track your progress.

mexas commented Mar 14, 2017

Damian, I'm listed as the maintainer on both links above.
If I find it's too much for me I'll pass it on
to ports@freebsd.org unless somebody else will be willing to take it up.
I think for standard repositories and standard paths, like yours, the
FreeBSD portscluster should pick it up automatically when an update
is available. Otherwise it's one of the port maintainers duties to track
the development of the code and update the port if and when required.
I'll try to track your progress.

@mexas

This comment has been minimized.

Show comment
Hide comment
@mexas

mexas Mar 14, 2017

To zbeekman, - yes probably can leave the relevant MPI port built with clang.
The general direction for FreeBSD ports system over the last few years has
been as much automation as possible. This has massive benefits, but sometimes
can mean an overkill. Anyway, when GCC 5 will become the default GCC port,
most of this complexity will go away and the users will be able to download and install
a prebuilt opencoarrays distribution for FreeBSD. For now some user interference is
needed.

Thanks

Anton

mexas commented Mar 14, 2017

To zbeekman, - yes probably can leave the relevant MPI port built with clang.
The general direction for FreeBSD ports system over the last few years has
been as much automation as possible. This has massive benefits, but sometimes
can mean an overkill. Anyway, when GCC 5 will become the default GCC port,
most of this complexity will go away and the users will be able to download and install
a prebuilt opencoarrays distribution for FreeBSD. For now some user interference is
needed.

Thanks

Anton

@zbeekman

This comment has been minimized.

Show comment
Hide comment
@zbeekman

zbeekman Mar 14, 2017

Member

In terms of OpenCoarrays, GCC-5 is still pretty behind the curve...

Member

zbeekman commented Mar 14, 2017

In terms of OpenCoarrays, GCC-5 is still pretty behind the curve...

@rouson

This comment has been minimized.

Show comment
Hide comment
@rouson

rouson Mar 14, 2017

Member

@zbeekman, that's certainly true, but GCC still lists 5 under "Supported Releases" and it's probably reasonable for us to mirror GCC's classifications. Nonetheless, I assume 5 will lose its status as a supported release not long after GCC 7, which hopefully is imminent.

Member

rouson commented Mar 14, 2017

@zbeekman, that's certainly true, but GCC still lists 5 under "Supported Releases" and it's probably reasonable for us to mirror GCC's classifications. Nonetheless, I assume 5 will lose its status as a supported release not long after GCC 7, which hopefully is imminent.

@rouson

This comment has been minimized.

Show comment
Hide comment
@rouson

rouson Apr 25, 2017

Member

I kept this open as a reminder to update the installation notes to mention the new FreeBSD option. I'm closing this as that need is part of the To DO list in issue #368.

Member

rouson commented Apr 25, 2017

I kept this open as a reminder to update the installation notes to mention the new FreeBSD option. I'm closing this as that need is part of the To DO list in issue #368.

@rouson rouson closed this Apr 25, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment