[erlang-questions] Bundling C dependencies with a release

[Radu Popescu]

Thanks to everyone for the advice!

I guess there are two main approaches: either link statically, as much stuff as possible, or continue with shared libraries and rely on the system’s package management support.

I’m already using a container for CI. Are there any issues with Erlang running on Alpine Linux (I think there is a problem in ver 3.5 which switched from OpenSSL to LibreSSL)? Building on this distribution using the Musl C library could simplify the static approach.

Cheers,
Radu

> On 25 Oct 2016, at 18:59, John Doe <donpedrothird@REDACTED> wrote:
> 
> For portable app you'll need to compile as many libs as possible statically. With pure C libraries it's usually easy to do so, but you will have a lot of problems with c++ executables and libraries, as libstdc++ has different ABI in different gcc releases. You'd need to compile libstdc++ statically, and also anything that links against c++ code with -static-libstdc++ and -fPIC. The libstdc++ itself should be built with -fPIC flag. 
> When I need portable binaries I compile gcc myself from sources prior to linking against static libstdc++, with 
> ./configure CXXFLAGS=-fPIC CFLAGS=-fPIC --enable-languages=c,c++ --disable-gnu-unique-object --disable-multilib 
> 
> Also you could get problems with openssl if you use the crypto app. There are many different versions built of openssl each with different set of algorithms, so it is better to compile your own openssl with something like this:
> wget https://www.openssl.org/source/openssl-1.0.2h.tar.gz <https://www.openssl.org/source/openssl-1.0.2h.tar.gz>
> tar -xvzf openssl-1.0.2h.tar.gz
> cd openssl-1.0.2h/
> ./config --prefix=/usr shared -fPIC
> make depend && make && make install
> and then have otp built with
> --disable-dynamic-ssl-lib --with-ssl=/usr/ --enable-smp-support --without-termcap --enable-dirty-schedulers --enable-builtin-zlib 
> 
> 
> You can even patch the OTP if you need it to work with relative install path (warning - the patch contains bashisms): http://pastebin.com/FJtRNRMJ <http://pastebin.com/FJtRNRMJ>
> 
> All that stuff should be done on a dedicated build server or VPS, as it could break a lot of things in the system. But as the result the app is very portable. If built on x64 box, it would work on most x64 bit linux servers with any distro.
> 
> nif apps should be also built with something like this:
> 
> {"CXXFLAGS", "$CXXFLAGS -std=c++11 -Wall -fPIC -g3 -static-libstdc++"},
> {"DRV_LDFLAGS", "$DRV_LDFLAGS c_src/libsomeapp.a c_src/system/lib/libsnappy.a c_src/system/lib/liblz4.a c_src/system/lib/libz.a c_src/system/lib/libbz2.a /usr/lib64/
> gcc/x86_64-pc-linux-gnu/5.3.0/libstdc++.a  -static-libstdc++"}]}.
> 
> 
> 2016-10-25 15:35 GMT+03:00 Radu Popescu <i.radu.popescu@REDACTED <mailto:i.radu.popescu@REDACTED>>:
> Hello!
> 
> I'm developing an Erlang application which is structured as an OTP release. It contains OTP applications and some native executables (written in C++). One of the Erlang dependencies also requires libsodium.
> 
> When the time will come to deploy this - mostly to RH and Ubuntu/Debian servers, the idea is to have something as self-contained as possible.
> 
> Are there best practices for how to handle C library dependencies for an Erlang/OTP release? I appreciate any advice.
> 
> Thanks!
> 
> Best regards,
> Radu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions <http://erlang.org/mailman/listinfo/erlang-questions>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161026/d2d04763/attachment.htm>