(lldb) target create -core '/cores/core.3259' Core file '/cores/core.3259' (x8664) was loaded. Added a comment - 09/Jun/17 1:34 AM Status 139 is segfault (139-128=11). I enabled core files (ulimit -c unlimited) and re-ran - I get the following core dump backtrace (LLDB is as always being helpful and making me guess which was the crashing thread). (lldb) target create -core '/cores/core.3259' Core file '/cores/core.3259' (x8664) was loaded. Added a comment - 18/Jun/17 3:29 PM - edited Dave - thanks for the awesome debugging - looks like it's the crypto:randuniformnif that's causing the problem. Frame #5: 0x824fd2 crypto.so`randuniformnif + 258 Can you try running: ' crypto:randuniform(0,100).

' in a shell-started Erlang VM to see if you get the same behavior? Also: have you brew installed openssl - or are you picking up whatever is in highsierra? And this raises a good question: what is in highsierra? Is it missing libcrypto?

I think we pick it up from /usr/lib/libcrypto.0.9.8.dylib in earlier versions of Mac OS - but others CC'ed perhaps know this better than me. (lldb) image list. 214 EED238EC-C051-302A-926C-0B9FE4544FD2 0x00007fffc3a8d000 /usr/lib/libcrypto.0.9.8.dylib A bit of digging suggests that Apple has moved from OpenSSL to libreSSL in High Sierra: There's also a very interesting comment on by idyll: Also of note. Apple has bundled LibreSSL on the system but is using a custom version BoringSSL internally as well. This causes issues with dynamic linking as some things grab the wrong SSL.

(Erlang for example.) I am hoping Apple fixes this in the next beta because they don't want people using their BoringSSL. Anything that isn't TWOLEVEL has issues right now. Aka FLATNAMESPACE. You can check with otool -hV I will report back on this once I have more info. Added a comment - 19/Jun/17 1:27 AM Can you try running: 'crypto:randuniform(0,100).'

In a shell-started Erlang VM to see if you get the same behavior? With the original Spock Beta binary (and my locally compiled one) it crashes immediately: $ COUCHBASETOP=$PWD bin/erl Erlang R16B03-1 (erts-5.10.4.0.0.1) source-3ea8397 64-bit smp:16:16 async-threads:10 kernel-poll:false Eshell V5.10.4.0.0.1 (abort with ^G) 1 crypto:randuniform(0,100). Dave - I imagine that /usr/lib/libcrypto.0.9.8.dylib is LibreSSL (and not Boring.) However, interestingly Libre began its life as a fork of the openssl 1.0.1g branch.

,: The way I'd like to fix this for spock is to bundle openssl 0.9.8 with Mac. This aligns with discussions I've had with Trond recently on whether or not we should adopt Secure Transport. (TL; DR - adopting Secure Transport requires us to move to PKSC#12 format with passphrases - this is not at all easy to do. In fact the only way I know of generating these certs is to use openssl to convert from.pem. Plus, as a developer platform using the same library as we do on Linux keeps things simplest.): can you comment on how easy it would be to bundle openssl 0.9.8 in the Mac build for spock? Added a comment - 19/Jun/17 11:46 AM Dave - I imagine that /usr/lib/libcrypto.0.9.8.dylib is LibreSSL (and not Boring.) However, interestingly Libre began its life as a fork of the openssl 1.0.1g branch. ( ) Chris Hillery, Trond Norbye: The way I'd like to fix this for spock is to bundle openssl 0.9.8 with Mac.

This aligns with discussions I've had with Trond recently on whether or not we should adopt Secure Transport. (TL; DR - adopting Secure Transport requires us to move to PKSC#12 format with passphrases - this is not at all easy to do. In fact the only way I know of generating these certs is to use openssl to convert from.pem. Plus, as a developer platform using the same library as we do on Linux keeps things simplest.) Chris Hillery: can you comment on how easy it would be to bundle openssl 0.9.8 in the Mac build for spock?

Ok, I've proposed a change to create an OpenSSL 1.0.2k cbdeps package for MacOS, and built it - it's available here: However there are a lot of stuffs in that package that I don't understand or know anything about, so I'd like to punt this to someone with experience working with OpenSSL (and on MacOS). To finish this up, I'll need to know what bits need to be installed with Couchbase Server Currently it copies the bin/, lib, and include/ directories into CMAKEINSTALLPREFIX, which is almost certainly wrong. I don't know what to do with 'certs', 'misc', 'openssl.cnf', or 'private'.

(I'm pretty sure I can delete 'man' from the cbdeps package.) I'll also need help to determine whether other parts of Couchbase Server's build scripts will need to be changed to pick up this library in preference to one installed on the system. And, finally, the scary part, I'll need to know whether we need to rebuild cbdeps like Erlang and Curl to use this openssl.

Assigning to Trond for the moment. Added a comment - 21/Jun/17 10:39 PM Ok, I've proposed a change to create an OpenSSL 1.0.2k cbdeps package for MacOS, and built it - it's available here: However there are a lot of stuffs in that package that I don't understand or know anything about, so I'd like to punt this to someone with experience working with OpenSSL (and on MacOS). To finish this up, I'll need to know what bits need to be installed with Couchbase Server Currently it copies the bin/, lib, and include/ directories into CMAKEINSTALLPREFIX, which is almost certainly wrong. I don't know what to do with 'certs', 'misc', 'openssl.cnf', or 'private'. (I'm pretty sure I can delete 'man' from the cbdeps package.) I'll also need help to determine whether other parts of Couchbase Server's build scripts will need to be changed to pick up this library in preference to one installed on the system.

And, finally, the scary part, I'll need to know whether we need to rebuild cbdeps like Erlang and Curl to use this openssl. Assigning to Trond for the moment. Added a comment - 07/Jul/17 8:58 AM Upstream have a fix - see. I've ported this to our branch (see ) and built locally (macOS High Sierra).

Crypto seems much happier now: $./install/bin/erl Erlang R16B03-1 (erts-5.10.4.0.0.1) source-70bac3534 64-bit smp:16:16 async-threads:10 kernel-poll:false Eshell V5.10.4.0.0.1 (abort with ^G) 1 crypto:randuniform(0,100). 37 A quick test with./clusterrun shows the UI comes up and will initialise the cluster.

I'm not sure of the process for updates to our Erlang - I imagine someone from nsserver ( Aliaksey Artamonau?) will want to give the patch the OK, before build ( Chris Hillery?) pushes that commit to couchbasedeps? I think we might want to back out the above patch to build our own openSSL - the actual issue with this MB was Erlang not being built correctly for High Sierra's SSL library; I have a fix in testing (backport of upstream Erlang patch) which tweaks the build options for erlang and solves the crash. If we /do/ include our own OpenSSL build, then it adds more maintenance cost for us if/when there's any OpenSSL bugs in future, which I'm sure everyone would want.

Furthermore, it doesn't actually solve the bug - we'd have to rebuild Erlang (and any other consumers of OpenSSL) anwyays to link against our shipped OpenSSL and not the system one. Added a comment - 12/Jul/17 12:46 AM Chris Hillery I think we might want to back out the above patch to build our own openSSL - the actual issue with this MB was Erlang not being built correctly for High Sierra's SSL library; I have a fix in testing (backport of upstream Erlang patch) which tweaks the build options for erlang and solves the crash.

If we /do/ include our own OpenSSL build, then it adds more maintenance cost for us if/when there's any OpenSSL bugs in future, which I'm sure everyone would want. Furthermore, it doesn't actually solve the bug - we'd have to rebuild Erlang (and any other consumers of OpenSSL) anwyays to link against our shipped OpenSSL and not the system one. Hmm, that wasn't clear from the earlier discussion. Still, don't we need both, since other parts of our system link against openssl as well? The underlying issue with High Sierra appears to be that Apple has changed how they build their libcrypto, which requires linking with twolevel (not flat) namespace.

Twolevel is the default (and so I think our other binaries are fine), but Erlang seemed to have chosen flat in the past for some reason. Therefore I believe that only Erlang needs changing to fix the issue (although some others may come out of the woodwork). Added a comment - 12/Jul/17 1:22 AM Hmm, that wasn't clear from the earlier discussion.

Still, don't we need both, since other parts of our system link against openssl as well? The underlying issue with High Sierra appears to be that Apple has changed how they build their libcrypto, which requires linking with twolevel (not flat) namespace. Twolevel is the default (and so I think our other binaries are fine), but Erlang seemed to have chosen flat in the past for some reason. Therefore I believe that only Erlang needs changing to fix the issue (although some others may come out of the woodwork). Added a comment - 14/Jul/17 2:14 AM I've pushed Dave's change up to github.com/couchbasedeps/erlang, and kicked off the Erlang build on MacOS only: Once that's done, we can publish the new package to S3 using, which should allow final testing (on a Mac) of Dave's gerrit review. Assuming that all goes smoothly, we should probably roll back my OpenSSL change, or at least the manifest.cmake part of it.

Personally I'd like to keep it for memcached due to the fact that it does add support for TLS 1.2 and allows people to test out their app in the way it'll be deployed when they go live (the deployments numbers indicates that people normally deploy on Linux; where they'll find a newer version of OpenSSL). Bundling OpenSSL does introduce extra maintenance costs for us, but we're already bundling OpenSSL for another EE version so we need to keep an eye open for security issues anyway. As a side node MacOSX is EE, but only intended for development and not deployment (which also lowers the impact of security issues as developers can stop their development server if they're in an insecure environment (or start a server in a VM)). Ideally we should rebuild Erlang to use our bundled version, but we don't have to do that immediately as they work with the version the OS provides. From my understanding Erlang only use the crypto interface (someone should provide a patch to use the common crypto interface instead ). When it comes to curl: it is used (library) from moxi (but not any openssl related functions) and collectinfo (the binary).

On my mac (sierra) it is actually newer than the one we bundle (7.49.1) and built using SecureTransport. Added a comment - 17/Jul/17 11:07 PM Chris Hillery - Personally I'd like to keep it for memcached due to the fact that it does add support for TLS 1.2 and allows people to test out their app in the way it'll be deployed when they go live (the deployments numbers indicates that people normally deploy on Linux; where they'll find a newer version of OpenSSL). Bundling OpenSSL does introduce extra maintenance costs for us, but we're already bundling OpenSSL for another EE version so we need to keep an eye open for security issues anyway. As a side node MacOSX is EE, but only intended for development and not deployment (which also lowers the impact of security issues as developers can stop their development server if they're in an insecure environment (or start a server in a VM)).

Ideally we should rebuild Erlang to use our bundled version, but we don't have to do that immediately as they work with the version the OS provides. From my understanding Erlang only use the crypto interface (someone should provide a patch to use the common crypto interface instead ). When it comes to curl: it is used (library) from moxi (but not any openssl related functions) and collectinfo (the binary). On my mac (sierra) it is actually newer than the one we bundle (7.49.1) and built using SecureTransport: trond@ok:1035 curl -version curl 7.51.0 (x8664-apple-darwin16.0) libcurl/7.51.0 SecureTransport zlib/1.2.8 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLMWB SSL libz UnixSockets.

2 Building and Installing Erlang/OTP This document describes how to build and install Erlang/OTP-21. Erlang/OTP should be possible to build from source on any Unix/Linux system, including OS X. You are advised to read the whole document before attempting to build and install Erlang/OTP. The source code can be downloaded from the official site of Erlang/OTP or GitHub.

These are the tools you need in order to unpack and build Erlang/OTP. GNU unzip, or a modern uncompress. A TAR program that understands the GNU TAR format for long filenames. GNU make. Compiler - GNU C Compiler, gcc or the C compiler frontend for LLVM, clang. Perl 5.

GNU m4 - If HiPE (native code) support is enabled. HiPE can be disabled using -disable-hipe. ncurses, termcap, or termlib - The development headers and libraries are needed, often known as ncurses-devel. Use -without-termcap to build without any of these libraries. Note that in this case only the old shell (without any line editing) can be used. sed - Stream Editor for basic text transformation. Building in Git.

GNU autoconf of at least version 2.59. Note that autoconf is not needed when building an unmodified version of the released source.

Building on OS X. Xcode - Download and install via the Mac App Store. Read about before proceeding. An install program that can take multiple file names. Some applications are automatically skipped if the dependencies aren't met. Here is a list of utilities needed for those applications.

Erlangfor Mac Os Download

You will also find the utilities needed for building the documentation. OpenSSL - The opensource toolkit for Secure Socket Layer and Transport Layer Security. Required for building the application crypto. Further, ssl and ssh require a working crypto application and will also be skipped if OpenSSL is missing. The publickey application is available without crypto, but the functionality will be very limited. The development package of OpenSSL including the header files are needed as well as the binary command program openssl.

At least version 0.9.8 of OpenSSL is required. Read more and download from. Oracle Java SE JDK - The Java Development Kit (Standard Edition). Required for building the application jinterface. At least version 1.6.0 of the JDK is required. Download from. We have also tested with IBM's JDK 1.6.0.

Erlangfor Mac Os 7

flex - Headers and libraries are needed to build the flex scanner for the megaco application on Unix/Linux. wxWidgets - Toolkit for GUI applications. Required for building the wx application.

At least version 3.0 of wxWidgets is required. Download from or get it from GitHub: Further instructions on wxWidgets, read.

xsltproc - A command line XSLT processor. A tool for applying XSLT stylesheets to XML documents. Download xsltproc from. fop - Apache FOP print formatter (requires Java). Can be downloaded from. The following instructions are for building. The variable $ERLTOP will be mentioned a lot of times.

It refers to the top directory in the source tree. More information about $ERLTOP can be found in the section below. If you are building in git you probably want to take a look at the section below before proceeding. Start by unpacking the Erlang/OTP distribution file with your GNU compatible TAR program. $ cd $ tar -zxf otpman21.2.tar.gz Where is. /lib/erlang if you have installed Erlang/OTP using make install. $DESTDIR/lib/erlang if you have installed Erlang/OTP using make install DESTDIR=.

RELEASEROOT if you have installed using make release RELEASEROOT=. If you want to tailor your Erlang/OTP build and installation, please read on for detailed information about the individual steps.

All the makefiles in the entire directory tree use the environment variable ERLTOP to find the absolute path of the installation. The configure script will figure this out and set it in the top level Makefile (which, when building, it will pass on). However, when developing it is sometimes convenient to be able to run make in a subdirectory. To do this you must set the ERLTOP variable before you run make. For example, assume your GNU make program is called make and you want to rebuild the application STDLIB, then you could do. $ export MAKEFLAGS=-j8 # Assuming bash/sh $ make If you've upgraded the source with a patch you may need to clean up from previous builds before the new build. Make sure to read the section below before doing a make clean.

Within Git When building in a Git working directory you also have to have a GNU autoconf of at least version 2.59 on your system, because you need to generate the configure scripts before you can start building. The configure scripts are generated by invoking./otpbuild autoconf in the $ERLTOP directory. The configure scripts also have to be regenerated when a configure.in or aclocal.m4 file has been modified. Note that when checking out a branch a configure.in or aclocal.m4 file may change content, and you may therefore have to regenerate the configure scripts when checking out a branch.

Regenerated configure scripts imply that you have to run configure and build again. Running./otpbuild autoconf is not needed when building an unmodified version of the released source. Other useful information can be found at our GitHub wiki:. OS X (Darwin) Make sure that the command hostname returns a valid fully qualified host name (this is configured in /etc/hostconfig). Otherwise you might experience problems when running distributed systems.

If you develop linked-in drivers (shared library) you need to link using gcc and the flags -bundle -flatnamespace -undefined suppress. You also include -fno-common in CFLAGS when compiling. Use.so as the library suffix. If you have Xcode 4.3, or later, you will also need to download 'Command Line Tools' via the Downloads preference pane in Xcode. Building with wxErlang If you want to build the wx application, you will need to get wxWidgets-3.0 ( wxWidgets-3.0.3.tar.bz2 from ) or get it from github with bug fixes.

Doing make clean in an arbitrary directory of the source tree, may remove files needed for bootstrapping the build. Doing./otpbuild savebootstrap from the $ERLTOP directory before doing make clean will ensure that it will be possible to build after doing make clean./otpbuild savebootstrap will be invoked automatically when make is invoked from $ERLTOP with either the clean target, or the default target. It is also automatically invoked if./otpbuild removeprebuiltfiles is invoked. If you need to verify the bootstrap beam files match the provided source files, use./otpbuild updateprimary to create a new commit that contains differences, if any exist. How to Build a Debug Enabled Erlang RunTime System After completing all the normal building steps described above a debug enabled runtime system can be built.

To do this you have to change directory to $ERLTOP/erts/emulator and execute. $ make DESTDIR= install The installation will be created in a location prefixed by $DESTDIR.

It can, however, not be run from there. It needs to be moved into the correct location before it can be run. If DESTDIR have not been set but INSTALLPREFIX has been set, DESTDIR will be set to INSTALLPREFIX. Note that INSTALLPREFIX in pre R13B04 was buggy and behaved as EXTRAPREFIX (see below). There are lots of areas of use for an installation procedure using DESTDIR, e.g. When creating a package, cross compiling, etc. Here is an example where the installation should be located under /opt/local.

$./configure -prefix=/opt/local $ make $ make DESTDIR=/tmp/erlang-build install $ cd /tmp/erlang-build/opt/local $ # gnu-tar is used in this example $ tar -zcf /home/me/my-erlang-build.tgz. $ su - Password:. $ cd /opt/local $ tar -zxf /home/me/my-erlang-build.tgz. Install using the release target.

Instead of doing make install you can create the installation in whatever directory you like using the release target and run the Install script yourself. RELEASEROOT is used for specifying the directory where the installation should be created. This is what by default ends up under /usr/local/lib/erlang if you do the install using make install. All installation paths provided in the configure phase are ignored, as well as DESTDIR, and INSTALLPREFIX. If you want links from a specific bin directory to the installation you have to set those up yourself. An example where Erlang/OTP should be located at /home/me/OTP.

$./Install -cross -minimal -sasl where:.minimal Creates an installation that starts up a minimal amount of applications, i.e., only kernel and stdlib are started. The minimal system is normally enough, and is what make install uses.sasl Creates an installation that also starts up the sasl application.cross For cross compilation. Informs the install script that it is run on the build machine.

The absolute path to the Erlang installation to use at run time. This is often the same as the current working directory, but does not have to be. It can follow any other path through the file system to the same directory.

If neither -minimal, nor -sasl is passed as argument you will be prompted. Test install using EXTRAPREFIX. The content of the EXTRAPREFIX variable will prefix all installation paths when doing make install. Note that EXTRAPREFIX is similar to DESTDIR, but it does not have the same effect as DESTDIR. The installation can and have to be run from the location specified by EXTRAPREFIX. That is, it can be useful if you want to try the system out, running test suites, etc, before doing the real install without EXTRAPREFIX. Symbolic Links in -bindir When doing make install and the default installation prefix is used, relative symbolic links will be created from /usr/local/bin to all public Erlang/OTP executables in /usr/local/lib/erlang/bin.

The installation phase will try to create relative symbolic links as long as -bindir and the Erlang bin directory, located under -libdir, both have -exec-prefix as prefix. Where -exec-prefix defaults to -prefix.prefix, -exec-prefix, -bindir, and -libdir are all arguments that can be passed to configure. One can force relative, or absolute links by passing BINDIRSYMLINKS=relative absolute as arguments to make during the install phase. Note that such a request might cause a failure if the request cannot be satisfied. Using HiPE HiPE supports the following system configurations:. x86: All 32-bit and 64-bit mode processors should work. Linux: Fedora Core is supported.

Both 32-bit and 64-bit modes are supported. NPTL glibc is strongly preferred, or a LinuxThreads glibc configured for 'floating stacks'. Old non-floating stacks glibcs have a fundamental problem that makes HiPE support and threads support mutually exclusive. Solaris: Solaris 10 (32-bit and 64-bit) and 9 (32-bit) are supported. The build requires a version of the GNU C compiler (gcc) that has been configured to use the GNU assembler (gas).

Sun's x86 assembler is emphatically not supported. FreeBSD: FreeBSD 6.1 and 6.2 in 32-bit and 64-bit modes should work. OS X/Darwin: Darwin 9.8.0 in 32-bit mode should work. PowerPC: All 32-bit 6xx/7xx(G3)/74xx(G4) processors should work. 32-bit mode on 970 (G5) and POWER5 processors should work. Linux (Yellow Dog) and OS X 10.4 are supported. SPARC: All UltraSPARC processors running 32-bit user code should work.

Solaris 9 is supported. The build requires a gcc that has been configured to use Sun's assembler and linker. Using the GNU assembler but Sun's linker has been known to cause problems. Linux (Aurora) is supported. ARM: ARMv5TE (i.e. XScale) processors should work.

Both big-endian and little-endian modes are supported. Linux is supported. HiPE is automatically enabled on the following systems:. x86 in 32-bit mode: Linux, Solaris, FreeBSD. x86 in 64-bit mode: Linux, Solaris, FreeBSD.

PowerPC: Linux, Mac OSX. SPARC: Linux.

ARM: Linux On other supported systems, see on how to enable HiPE. If you are running on a platform supporting HiPE and if you have not disabled HiPE, you can compile a module into native code like this from the Erlang shell.