[erlang-questions] R14B04 and OpenSSL 1.0.1c

Stanislav Sedov stas@REDACTED
Wed May 22 10:46:45 CEST 2013


On May 22, 2013, at 12:34 AM, Bogdan Andu <bog495@REDACTED> wrote:

> The os is OpenBSD 5.3 amd64 with preinstalled opensssl library /usr/lib/libssl.so.19.0
> 
> $ /usr/sbin/openssl 
> OpenSSL> version
> OpenSSL 1.0.1c 10 May 2012
> OpenSSL> 
> ^D
> 
> This is the only ssl library in the system, and erlang was configured with this ssl library 
> and no complaints at ./configure time.
> 
> On the other hand:
> 
> On OpenBSD 5.2 amd64 with preinstalled opensssl library /usr/lib/libssl.so.18.0
> 
> $ /usr/sbin/openssl 
> OpenSSL> version
> OpenSSL 1.0.0f 4 Jan 2012
> OpenSSL> 
> ^D
> 
> everything works perfect, and Erlang was also configured againsat this preinstalled library
> 

I found this message on the mailing list, which seems to be relevant:
http://www.mail-archive.com/cdesktopenv-devel@lists.sourceforge.net/msg00598.html

It looks like the __guard_local symbol is generated by new stack_protector code,
and according to the patch it seems that linking against libcrtbeginS.o and
libcrtendS.o fixes the issue for CDE.  It might be worth trying to modify the
erlang linker flags (or at least crypto linking flags) to link against these
objects.

However, I don't really understand what's going on here.  According to [1],
the new __guard_local symbol should be present in crtbegin.o.  But maybe crypto.so
is being linked manually by erlang build system (i.e. not via cc(1)), in which case
applying the same fix as was provided for CDE might help.

[1]: http://openbsd.7691.n7.nabble.com/GCC-diff-needs-testing-on-multiple-arches-td167891.html

--
ST4096-RIPE






More information about the erlang-questions mailing list