Thank you all for your answers. The migration to R15 or even R16 is complicated, as a lot of code must be modified and a lot of teste must be conducted in order to make things correctly.
The fact is newer does not make it better. There are so many applications that run a lot better in R14 than in R15 The migration is very tricky and upgrading production code only to have R15 does not make any sense to me and I'm happy with R14. On the other hand I have applied the patches: cd $OTP_SRC_DIRR14B04 patch -p0 < /usr/ports/lang/erlang/patches/patch-erts_configure_in patch -p0 < /usr/ports/lang/erlang/patches/patch-erts_emulator_Makefile_in patch -p0 < /usr/ports/lang/erlang/patches/patch-erts_lib_src_Makefile_in patch -p0 < /usr/ports/lang/erlang/patches/patch-lib_tools_c_src_Makefile_in patch -p0 < /usr/ports/lang/erlang/patches/patch-make_target_mk *all patches succedded, and then: ./configure sudo gmake install the same error I modified erts/configure.in: from: openbsd*) DED_LD="$CC" DED_LD_FLAG_RUNTIME_LIBRARY_PATH="$CFLAG_RUNTIME_LIBRARY_PATH" DED_LDFLAGS="-shared" ;; in: openbsd*) DED_LD="$CC" DED_LD_FLAG_RUNTIME_LIBRARY_PATH="$CFLAG_RUNTIME_LIBRARY_PATH" DED_LDFLAGS="-shared /usr/lib/crtbeginS.o /usr/lib/crtbegin.o" ;; because: $ nm /usr/lib/crtbegin.o U _GLOBAL_OFFSET_TABLE_ U _Jv_RegisterClasses 00000000 D __dso_handle 00000000 T __fini 00000000 D __guard_local 00000000 T __init 00000000 W __register_frame_info U atexit $ nm /usr/lib/crtbeginS.o U _GLOBAL_OFFSET_TABLE_ U _Jv_RegisterClasses U __cxa_finalize 00000000 D __dso_handle 00000000 D __guard_local 00000000 T _fini 00000000 T _init gmake clean ./configure sudo gmake install the same error In the topic I opened here brings Stanislav Sedov has a very strong opinion about this error (but does not solve my problem): https://groups.google.com/forum/?hl=en&fromgroups#!topic/erlang-programming/q lHg-RXa0x4 He says: "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." Does anyone has an idea of how to solve this issue, because I really need R14B04. Please help. I am really out of ideas. Maybe I should link against other libraries but I do not know what they are. How can I dicover these libraries that I should link erlang against? Bogdan ________________________________ From: Matthew Dempsky <matt...@dempsky.org> To: Bogdan Andu <bo...@yahoo.com> Cc: "misc@openbsd.org" <misc@openbsd.org> Sent: Thursday, May 23, 2013 9:04 AM Subject: Re: __guard_local issue On Wed, May 22, 2013 at 3:30 AM, Bogdan Andu <bo...@yahoo.com> wrote: > I compile from source Erlang R14B04 on a freshly installed OpenBSD 5.3 amd64 machine, configured with preinstalled opensssl library /usr/lib/libssl.so.19.0 . This was fixed upstream in R15B03: https://github.com/erlang/otp/commit/c282f35cf30d87b61baa30cc7b57ed8c858759ef Our R15B02 port includes the same fix. You should be able to backport it to R14B04 without trouble if you need to stick with an older Erlang release.
