Hello.
We have several different deployment targets, all Intel x86-64 platform. However, one is an outdated Linux image with lots of proprietary code that we cannot get rid off for several months still. We don’t have a true cross-compilation environment - the provider of the image never provided one. So what we did before to compile for this particular target is disable options that were not supported there and just use an Erlang ERTS compiled somewhere else. So far it was sufficient to go without a termcap library, mostly.
We tried to upgrade from Erlang/OTP 22.3 to 25.3, and for doing so, we would compile a version of Erlang with our additional options - like --without-termcap - so we could bundle the ERTS in our releases for that target. However, for the outdated image only we hit with a new problem that hadn’t existed up to and including OTP 22.3 - it now dynamically links libstdc++. And that particular target doesn’t provide one to satisfy it - and we get dynamical loading error when the beam.smp application is started.
The configure script for Erlang/OTP doesn’t explicitly mention it, but can the stuff that requires libstdc++ be disabled with a commandline option? Or alternatively, if that’s not possible, could we configure it to link in a static version of libstdc++ from the build machine?
We really, really cannot updated that old image, so I need a plan B. All our other deployment targets are adapted to Erlang/OTP 25.3, the rollout was going smoothly, and now we hit this stumbling block - and it’s a dozy…
Thanks for any pointers!!