Bundling C dependencies with a release

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

Bundling C dependencies with a release

Radu Popescu
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Bundling C dependencies with a release

Gleb Vinogradov
Hi Radu.

I don't bundle deps in release. I thing all dependencies should be handled by system packet manager, so you never miss security updates.
for Debian:
I'm creating a *.deb packet for my application with all dependencies listed. Then I simply install it with this command - 'dpkg -i release.deb && apt-get -f install'. If you want, you can create repository for your application, add it to /etc/apt/sources.list, and install it via 'apt-get install your_application'.
I'm pretty sure you can do similar thing for RH servers as well.

Best regards,
Gleb.

2016-10-25 19:35 GMT+07:00 Radu Popescu <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Bundling C dependencies with a release

Nathan Fiedler-2
In reply to this post by Radu Popescu
I don't know about best practices, but compiling the code and copying it to the "priv" directory seems to work well. The pre_hooks in rebar are very helpful for this. By using the priv dir, everything gets included as part of the release, at least with rebar3. Just zip up or copy the "rel" directory under _build and you're good to go.

Hope that helps.

n


On Tue, Oct 25, 2016 at 5:35 AM, Radu Popescu <[hidden email]> wrote:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Bundling C dependencies with a release

Max Lapshin-2
In reply to this post by Gleb Vinogradov
we pack all that we need into our /opt/flussonic and this help us to avoid problems of maintaining about 30 well known versions of ubuntu/debian/centos/redhat.

Just compile all libraries to your private root, then compile OTP there and then pack your beams there. 
It works.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Bundling C dependencies with a release

Daniel Goertzen-3
In reply to this post by Radu Popescu
Consider statically linking libsodium to your native executable to eliminate the runtime dependency.

On Tue, Oct 25, 2016 at 8:50 AM Radu Popescu <[hidden email]> wrote:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Bundling C dependencies with a release

John Doe
In reply to this post by Radu Popescu
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
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

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 <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
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

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 <[hidden email]>:
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
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Bundling C dependencies with a release

Max Lapshin-2
Wrong.

We compile ssl dynamically and put it to /opt/flussonic

It is used by erlang and by python  (we use both in our Flussonic).  And we do not rely on package manager.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions