Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
After the upgrade, ejabberd drops connections from pidgin and gajim. The error in gajim side looks like: 2007-07-06 17:05:42,916 gajim.c.x.transports_nb: ERROR: Connection to 2002:5121:1fe9:0:230:65ff:fe26:fe5c lost: Unexpected EOF [-1] and in the server like: =INFO REPORT==== 2007-07-06 17:02:45 === I(<0.230.0>:ejabberd_listener:90): (#Port<0.371>) Accepted connection {{127,0,0, 1},34657} -> {{127,0,0,1},5348} =INFO REPORT==== 2007-07-06 17:02:45 === I(<0.373.0>:ejabberd_service:321): terminated: {badarg, [{ets, lookup, [crypto_server_table,port]}, {crypto,control,2}, {sha,sha,1}, {ejabberd_service, wait_for_handshake, 2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p,5}]} =ERROR REPORT==== 2007-07-06 17:02:45 === ** State machine <0.373.0> terminating ** Last event in was {xmlstreamelement, {xmlelement, "handshake", [], [{xmlcdata, <<"adcb2e01e0e75f0151e739395eb9328cac6a0f00">> }]}} ** When State == wait_for_handshake ** Data == {state,#Port<0.371>, <0.374.0>, "4011231875", gen_tcp, ["icq.marlow.memojo.com"], "test", all} ** Reason for termination = ** {badarg,[{ets,lookup,[crypto_server_table,port]}, {crypto,control,2}, {sha,sha,1}, {ejabberd_service,wait_for_handshake,2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p,5}]} Downgrading to 11.2.4-r1 (plus all the associated problems to stop the daemon, that refuses to die with a "nodedown" error, but this is a different bug) makes it work again as expected Reproducible: Always Steps to Reproduce: 1. set up ejabberd with erlang-2.11.4-r1 2. upgrade erlang 3. enjoy! Actual Results: >What happened after you performed the steps above? See the summary Expected Results: >What should the software have done instead? give some messages intended for human beings in the log, at the very least :)
Which ejabberd version is this about?
net-im/ejabberd-1.1.3-r1
I can't reproduce this error.
Here with ejabberd 1.1.3 (not -r1), upgrading erlang from 11.2.4-r1 to 11.2.5 broke ejabberd in a similar way: =INFO REPORT==== 2007-07-13 12:13:46 === I(<0.234.0>:ejabberd_listener:90): (#Port<0.368>) Accepted connection {{89,1,121,27},48723} -> {{192,168,0,2},5222} =ERROR REPORT==== 2007-07-13 12:13:46 === ** State machine <0.327.0> terminating ** Last event in was {xmlstreamelement, {xmlelement, "iq", [{"type","set"}, {"id","auth_2"}, {"to","danarmak.homelinux.net"}], [{xmlcdata,<<"\n">>}, {xmlelement, "query", [{"xmlns","jabber:iq:auth"}], [{xmlcdata,<<"\n">>}, {xmlelement, "username", [], [{xmlcdata,<<"danarmak">>}]}, {xmlcdata,<<"\n">>}, {xmlelement, "digest", [], [{xmlcdata, <<"025bc9a5b0461a6d1c706afebbfdc3c67446104c">>}]}, {xmlcdata,<<"\n">>}, {xmlelement,"resource",[],[{xmlcdata,<<"Kopete">>}]}, {xmlcdata,<<"\n">>}]}, {xmlcdata,<<"\n">>}]}} ** When State == wait_for_auth ** Data == {state,#Port<0.368>, <0.328.0>, gen_tcp, "85411039", undefined, c2s, c2s_shaper, false, true, false, false, [{certfile,"/etc/jabber/ssl.pem"}], false, undefined, [], "danarmak.homelinux.net", [], undefined, {0,nil}, {0,nil}, {0,nil}, {0,nil}, undefined, undefined, undefined, false, none, []} ** Reason for termination = ** {badarg,[{ets,lookup,[crypto_server_table,port]}, {crypto,control,2}, {sha,sha,1}, {ejabberd_auth_internal,check_password,5}, {lists,any,2}, {ejabberd_c2s,wait_for_auth,2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p,5}]} And downgrading back to erlang 11.2.4-r1 fixed the issue.
This has been addressed in the 1.1.3-r2 ebuild by restricting the erlang dependency to <11.2.5 Thank you for your bug report.
*** Bug 188298 has been marked as a duplicate of this bug. ***
I can't this reproduce? Using erlang 11.2.5 :(
(In reply to comment #7) > I can't this reproduce? Using erlang 11.2.5 :( I removed old versions of erlang (but will restore them soon)....and also 11.2.5 is stable on all major arches. Can this problem be adressed differently? Is upstream informed?
To me at least the messages are quite readable :) The error occurs while looking up an ets table in crypto:control. This is an otp-internal application, which works just fine here using R11B5. The OP (or anyone able to reproduce this bug) could try to start an erlang shell and use sha standalone, eg: ~ $ erl Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] Eshell V5.5.5 (abort with ^G) 1> crypto:start(). ok 2> crypto:sha("Foo"). <<32,26,107,48,83,204,20,34,210,195,103,11,98,97,98,33,210,41,9,41>> 3> User switch command --> q If that works with erlang-R11B5 the OP should stop ejabberd before upgrading erlang, make shure all runtime processes (beam, epmd) terminated and after that restart ejabberd. Maybe that cures the problem. It might be interesting what USE-Flags you use for erlang and ejabberd and how your ejabberd is configured (make shure to mask any passwords!). To me it seems this has nothing to do with ejabberd. Maybe it's an erlang bug, but honestly I don't think so ;) Regards, Michael
May I ask what is the OP? Also, the last comment looks like a request to do a test, but I can't really understand what is the request. I'm not sure if I can afford to upgrade erlang (which I use only for ejabberd) and remain without it working. Specially now that, according to the previous comments, there are no previous versions. Last time this happened, it was a clash between the libz used to compile openssl and the one used for erlang. Not sure what is the issue now.
(In reply to comment #10) > May I ask what is the OP? You are. The "original poster". > Also, the last comment looks like a request to do a test, but I can't really > understand what is the request. Start erl (which is an interactive shell for Erlang) and type in the commands he tells in comment #9. > I'm not sure if I can afford to upgrade erlang (which I use only for ejabberd) > and remain without it working. Specially now that, according to the previous > comments, there are no previous versions. I restored them right now. Please do the test. > Last time this happened, it was a clash between the libz used to compile > openssl and the one used for erlang. Not sure what is the issue now. >
results of crypto:start(). after upgrade (works as you posted in 5.5.4-r*). Not sure what this means: $ erl Erlang (BEAM) emulator version 5.5.5 [source] [64-bit] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.5.5 (abort with ^G) 1> crypto:start(). ok 2> sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.99>,normal} ** When Server state == {#Port<0.99>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.101>,normal} ** When Server state == {#Port<0.101>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.102>,normal} ** When Server state == {#Port<0.102>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.103>,normal} ** When Server state == {#Port<0.103>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.104>,normal} ** When Server state == {#Port<0.104>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.105>,normal} ** When Server state == {#Port<0.105>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.106>,normal} ** When Server state == {#Port<0.106>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.107>,normal} ** When Server state == {#Port<0.107>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.108>,normal} ** When Server state == {#Port<0.108>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.109>,normal} ** When Server state == {#Port<0.109>,[]} ** Reason for termination == ** {port_died,normal} sh: line 0: exec: crypto_drv: not found =ERROR REPORT==== 22-Aug-2007::09:23:12 === ** Generic server crypto_server terminating ** Last message in was {'EXIT',#Port<0.110>,normal} ** When Server state == {#Port<0.110>,[]} ** Reason for termination == ** {port_died,normal} =INFO REPORT==== 22-Aug-2007::09:23:12 === application: crypto exited: shutdown type: temporary
Thanks for testing. Something went wrong during your erlang upgrade. You are missing the crypto driver. This is a driver written in C used by erlang. Does /usr/lib/erlang/lib/crypto-1.5.1.1/ exist and has it any contents after upgrading erlang? The crypto application (used by ejabberd) fails while looking for /usr/lib/erlang/lib/crypto-1.5.1.1/priv/lib/crypto_drv.so. I realize you are on 64 Bit? Afaik the combination of 64Bit erlang and ejabberd is not recommended. Maybe that's the reason. This is no ejabberd problem for shure. Regards, Michael
It does not have to do with SSL support of erlang? (Just a wild guess.) Santiago and Dan, could you please provide the output of "emerge -pv ejabberd erlang" and your emerge --info?
If anybody is interessted. This here are my USE Flags. This works fine with erlang 11.2.5-r2 [ebuild R ] net-im/ejabberd-1.1.3-r2 USE="mod_muc mod_pubsub ssl web -debug -ldap -mod_irc -odbc" [ebuild R ] dev-lang/erlang-11.2.5-r2 USE="smp ssl -doc -emacs -hipe -java -kpoll -odbc -tk" Portage 2.1.3.6 (default-linux/x86/2007.0/server, gcc-4.2.0, glibc-2.6.1-r0, 2.6.18.8 i686) ================================================================= System uname: 2.6.18.8 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ Gentoo Base System release 1.12.10 Timestamp of tree: Wed, 22 Aug 2007 07:00:01 +0000 ccache version 2.4 [enabled] dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon64 -O3 -mmmx -m3dnow -msse -msse2 -msse3 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs -mfpmath=387" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=athlon64 -O3 -mmmx -m3dnow -msse -msse2 -msse3 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs -mfpmath=387" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://pandemonium.tiscali.de/pub/gentoo/" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -s -Wl,-z,now" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_COMPRESS="gzip" PORTAGE_COMPRESS_FLAGS="-f9" PORTAGE_RSYNC_EXTRA_OPTS="--delete-excluded --exclude-from=/etc/portage/rsync_excludes" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acpi apache2 berkdb bzip2 clamav crypt cups dedicated ftp gd iconv imap jabber javascript jpeg jpeg2k mailwrapper mbox mmx msn mysql mysqli ncurses nls nptl oscar pam pcre php png readline sasl session slang snmp sockets spell sse2 ssl symlink tiff truetype unicode usb vhosts x86 xinetd xml yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="none" Unset: CTARGET, INSTALL_MASK
(In reply to comment #14) > It does not have to do with SSL support of erlang? (Just a wild guess.) > Santiago and Dan, could you please provide the output of "emerge -pv ejabberd > erlang" and your emerge --info? Could be. /usr/lib/erlang/lib/crypto-1.5.1.1/priv/lib/crypto_drv.so needs openssl, according to the README >= 0.9.7.
(In reply to comment #15) > If anybody is interessted. This here are my USE Flags. This works fine with > erlang 11.2.5-r2 I certainly am. Sorry for being OT, but it's really a good thing to enable kpoll for erlang when using ejabberd. http://www.erlang-consulting.com/thesis/tcp_optimisation/tcp_optimisation.html Might be interesting stuff for the OP also. Michael
(In reply to comment #17) > (In reply to comment #15) > > If anybody is interessted. This here are my USE Flags. This works fine with > > erlang 11.2.5-r2 > > I certainly am. Sorry for being OT, but it's really a good thing to enable > kpoll for erlang when using ejabberd. > http://www.erlang-consulting.com/thesis/tcp_optimisation/tcp_optimisation.html > Might be interesting stuff for the OP also. > > Michael > Thanks for this hint :) Just actived kpoll for my erlang ...
> Thanks for testing. Something went wrong during your erlang upgrade. You are > missing the crypto driver. This is a driver written in C used by erlang. > Does /usr/lib/erlang/lib/crypto-1.5.1.1/ exist and has it any contents after > upgrading erlang? It is empty, does not exist at all. > The crypto application (used by ejabberd) fails while looking > for /usr/lib/erlang/lib/crypto-1.5.1.1/priv/lib/crypto_drv.so. > I realize you are on 64 Bit? Afaik the combination of 64Bit erlang and ejabberd > is not recommended. Maybe that's the reason. Then gentoo should mask ejabberd for gentoo-amd64, it is not currently, and it actually worked reasonably under the previous erlang version. > It does not have to do with SSL support of erlang? (Just a wild guess.) > Santiago and Dan, could you please provide the output of "emerge -pv ejabberd > erlang" $ emerge -pv ejabberd erlang These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] net-im/ejabberd-1.1.3-r2 USE="ldap mod_muc mod_pubsub ssl web -debug -mod_irc -odbc" 0 kB [ebuild U ] dev-lang/erlang-11.2.5-r2 [11.2.4-r1] USE="doc java kpoll smp ssl -emacs -hipe -odbc -tk" 0 kB Total: 2 packages (1 upgrade, 1 reinstall), Size of downloads: 0 kB > and your emerge --info? $ emerge --info Portage 2.1.2.12 (default-linux/amd64/2007.0/desktop, gcc-4.2.0, glibc-2.5-r4, 2.6.23-rc3-hrt2 x86_64) ================================================================= System uname: 2.6.23-rc3-hrt2 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz Gentoo Base System release 1.12.9 Timestamp of tree: Tue, 21 Aug 2007 22:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=nocona -O2 -pipe -ftree-vectorize" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="es_ES.UTF-8" LDFLAGS="-Wl,-O1" LINGUAS="es es_ES en" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/layman/voip /usr/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aac acl acpi aiglx alsa amd64 apache2 arts avahi avi bash-completion berkdb bitmap-fonts bluetooth bonjour cairo cdr cli cracklib crypt cups curl dbus dlloader dri dvd dvdr dvdread eds emboss encode esd evdev evo fam firefox fortran galago gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv icu iproute2 ipv6 isdnlog java jpeg kde kdehiddenvisibility kerberos lcms ldap libg++ libnotify logrotate lucene mad midi mikmod mmx mono mouse mp3 mpeg mudflap ncurses nls nptl nptlonly nsplugin obex ogg opengl openmp oss pam pcre pdf pdflib perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts udev unicode v4l v4l2 vorbis xinerama xml xorg xrandr xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" DVB_CARDS="usb-wt220u" ELIBC="glibc" INPUT_DEVICES="synaptics mouse evdev keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es es_ES en" USERLAND="GNU" VIDEO_CARDS="vesa i810 intel" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Maybe, which OpenSSL Version you are using? I am using here 0.9.8e-r1.
There was an internal gcc error when compiling the ssl directory (I just saw it in ebuild.log It tells me to attach the proprocessed C source, which I'm doing
Created an attachment (id=128855) [details] gcc told me to attach this (via ebuild.log, error while compiling erlang)
(In reply to comment #21) > There was an internal gcc error when compiling the ssl directory (I just saw it > in ebuild.log No wonder then. > It tells me to attach the proprocessed C source, which I'm doing I have no idea, what to do with it ;) In my experience "internal compiler errors" where always due to compiler bugs or bad hardware (ram). You are using 4.2.0, try to compile it with 4.1.2. Something for the gcc-guys imho. Michael
(In reply to comment #23) > You are using 4.2.0, try to compile it with 4.1.2. Something for the gcc-guys > imho. emerge gcc-4.1.2, then use gcc-config as explained in the GCC Upgrade Guide, just do a downgrade.
Agreed :) But it sounds like gcc-4.2.0 on amd64 has problems with the attached code, while it works on ~x86, which is what I use. No need to tell this to the gcc people? And, as this is imo neither an ejabberd nor an erlang bug, is it possible that ejabberd-1.1.3-r3 will allow erlang-11.2.5 again, at least on ~x86? :) Michael
Using 4.1.2 I got: x86_64-pc-linux-gnu-gcc -shared -o ../priv/lib/x86_64-pc-linux-gnu/crypto_drv.s o ../priv/obj/x86_64-pc-linux-gnu/crypto_drv.o /usr/lib64/libcrypto.a /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: / usr/lib64/libcrypto.a(x86_64cpuid.o): no se puede usar la reubicación R_X86_64_P C32 contra `OPENSSL_cpuid_setup' cuando se hace un objeto compartido; recompile con -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: f alló el enlace final: Valor erróneo wqhich, translating the Spanish parts, mean that I can't have R_X86_64_PC32 relocations against OPENSSL_cpuid_setup when building a shared object and then advises me to recompile with -fPIC (not sure of openssl or ejabberd) this happens quite ofte in this architecture due to broken builds/libtools/... that don't know that a lot of architectures require -fPIC for shared linking. $ objdump -r /usr/lib64/libcrypto.a | grep R_X86_64_PC32 | wc -l 9488 $ equery belongs /usr/lib64/libcrypto.a [ Searching for file(s) /usr/lib64/libcrypto.a in *... ] dev-libs/openssl-0.9.8e-r1 (/usr/lib64/libcrypto.a) so it looks like there is a bug in openssl-0.9.8e-r1 keep reporting
I was mostly sure the first time (this bug is old) I tried with 4.1.2. So now the problem is during linking, coming from the fact that erlangs links a static libcrypto.a, and this one (at least) is broken. Re-emerging openssl with -fPIC does not make it different at all Now, I'm not sure of the "rightness" of linking libcrypto.a into a .so, neither of the "relocation-safety" of the two erlang objects. Any of those things would still make it a erlang problem (I agree ejabberd is not suspect at all :)
Doing a round-up calling base-system, amd64 and toolchain, maybe they can advise as I can't solve it. Read from comment #14 on. Thanks a lot.
More info: substituting libcrypto.a and libssl.a by the corresponding .so in the (crypto|ssl)/c_src/Makefile.* makes erlang work, test right and run ejabberd. I'm no libtool guru, so I can't assess if the bug is in the openssl that amd64 builds or the way erlang uses .a in building a .so (which looks wrong to me) Also, there is a comment about "start using static libcrypto" there, which explains why previous versions worked and this one broke. So there is a change in the very thing that is failing that breaks ssl in this release, at least for amd64 and current openssl.
Could anyone take this to erlang upstream, after testing it with the latest openssl versions. Thanks.
ive added a small patch so that the build system does not ignore failures in subdirs ... so now erlang will fail to build on x86_64 rather than weird runtime behavior in other apps
looks like the build system "by design" defaults to linking statically to openssl ive tweaked the src_unpack so it does dynamic all the time
Works for me with last changes. cool!
net-im, chainsaw. Finally I changed the dependency for erlang in ejabberd, so it won't try to downgrade to something below 11.2.5. Thanks.
