Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.