ERL-133: Linux emulator doesn't get linked with libsctp

[OTP-Maintainer]

Original reporter: dotsimon
Affected version: OTP-18.3
Component: erts
Migrated from: https://bugs.erlang.org/browse/ERL-133

---

Configure attempts to find sctp_bindx (amongst others) but under Linux this requires libsctp. Based on the comments of commit e6b246fa this isn't the case for FreeBSD.

This branch adds the option --enable-sctp-link to erts/configure:
https://github.com/dotsimon/otp/tree/erts_configure_sctp_bindx

If --enable-sctp-link is given then libsctp is searched for during configure and subsequently included when linking. This allows the dynamic link loader to resolve it at the time the beam emulator is invoked rather than a later dlopen().

Even though I would never *not* want this, I didn't make this the default since I don't have a FreeBSD dev. environment to see if there are any possible side-effects. Nor would this be what you want if the build environment has SCTP but you distribute the emulator to machines that don't (although then I could argue that you should be using --disable-sctp anyway!).

[OTP-Maintainer]

raimo said:

The reason for this is not FreeBSD related.  There SCTP is in the base system so there is no need for any special treatment.

But we have had and probably still has exactly the situation that we compiled on SLES 10.. with SCTP support and had mixed customers where some had libsctp installed and some not, and it was not feasible to have two different compiled versions.

So what is the problem with the existing dlopen() solution; what problem does your patch solve?

[OTP-Maintainer]

dotsimon said:

Why add the extra complexity/delay/etc of dlopen if it's already known at build time that libsctp is required?
I'm not proposing to remove your really clever dynamic solution. I'm adding an option to let the system link loader do it's normal job.

[OTP-Maintainer]

raimo said:

Because if we introduce one simpler and more straightforward way of linking, some users maybe for example package maintainers will use the straightforward way, and the complicated way does not get tested on many platforms and silently rots.

Since the complicated way sometimes is necessary we want it to be used as often as possible so we can find and correct errors. The uglier the default solution the more important that it is tested.

If, however, there are situations where normal linking is necessary, we gladly will introduce this kind of flag.

Another solution would be to make normal linking the default and treat our current dlopen() solution as a special flag for special internal customers that we and they test on their particular platform.  This lowers the expectation that the dlopen() solution should work everywhere possible.  But that would be a product decision involving heavy customers...

[OTP-Maintainer]

dotsimon said:

This was precisely why I didn't make a pull request out of this nor make the new behaviour default since I suspected there were more considerations from your side.

We will (continue to) patch this locally for our own deployments regardless of the outcome of this bug. However, I still feel it has value to the community in general to use the standard system linking operations.

I agree that implementation of this (either as default or not) means that the other path runs the risk of becoming stale.

[OTP-Maintainer]

raimo said:

So why is it so valuable for you to use normal dynamic linking that you are willing to maintain a local patch?

I agree that using standard system linking operations has a merit of its own, but can not see in what way our dlopen() solution is such a problem...

Having standard system linking as the default and then a special flag for the dlopen() solution would be prettier.  Then the responsibility for the secondary path not going stale lands at the small subset of the ones using it.

[OTP-Maintainer]

dotsimon said:

Hi & sorry for the delayed reply.
I'm a little confused if you're agreeing or not that having this as a default is good/better than the current.
Anyway for us because we know we want sctp, it's two-fold:
# 1) Packaging (e.g. rpm) knows the libsctp dependency
# 2) It's the "right" way to do it 

[OTP-Maintainer]

raimo said:

I think we have two alternatives:
# No change from today
# Taking your patch but have the default to be normal dynamic linking, and an option for our current ugly dlopen() solution

Since the current solution is an ugly one that solves a problem I am looking for arguments for switching to alternative 2; more solid ones than that "it is the right way to do it".

[OTP-Maintainer]

dotsimon said:

Consider my two previous points reversed then: the primary motivator is packaging.
If beam is linked against a shared libsctp then a packaging tool (e.g. rpm) can note this dependency.
At install time, the dependency can be enforced and depending on the tool (e.g. zypper) can be fetched and installed.
The same applies if one is building a custom distribution - that the remastering tool can ensure all required libraries are present.
With the dlopen solution this isn't the case.
You have alluded to a problem that dlopen solves and so it's possible this is exactly what you don't want. However, in the general case the advantage to package managers is to solve or flag dependency issues.

[OTP-Maintainer]

raimo said:

There is a problem for the package creator, though.  When creating a package the package creator has to decide which build time options to select for the package, and for an application like Erlang there are many build time options.  So you get a flavour explosion - you have to select which package flavours to build and maintain; you only want a few flavours of a package, preferably one.

Therefore some run-time dependencies are soft for Erlang as for other applications.  The NIFs allow this and for example the crypto application will load its crypto NIF shared library that is built to link against the OpenSSL shared libraries.  But if there are no OpenSSL shared libraries the loading of the crypto NIF shared library will fail.  This happens when starting the crypto application, not when starting the emulator.  So this makes it possible to build fewer flavours of the Erlang package that still supports features that may or may not be installed in the OS.

We have a category of hard run-time dependencies that are required for the Erlang VM to start, and we have a category of soft run-time dependencies that will cause some applications to not start due to missing shared libraries in the OS installation.

The question is now to decide if the dependency to libsctp should be hard or soft.  We have previously made the decision that it should be soft because we had internal customers that did not have libsctp installed.

We have decided to keep this dependency to libsctp as soft for now.  When SCTP becomes even more commonly installed we will probably change this into a hard dependency. But not just yet.

Thank you for your contribution.

[OTP-Maintainer]

raimo said:

I now added a configure option --enable-sctp=lib to the 'maint' branch to compensate for a mistake when accepting https://github.com/erlang/otp/pull/1117.

This new switch value should do what you want, but the default is still --enable-sctp=yes.