Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 Dec 2009 22:08:23 -0500
From:      "b. f." <bf1783@googlemail.com>
To:        Ghirai <ghirai@ghirai.com>
Cc:        freebsd-questions@FreeBSD.org
Subject:   Re: ld-elf related problems
Message-ID:  <d873d5be0912201908v50c33e87j65798165cdd3b1d1@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
>I'm running 8.0-RELEASE amd64, and various applications randomly
>coredump and exit with signal 10; this has started apparently after
>installing numpy from ports, which also pulled gcc44.
>Right after that basically all apps i had running crashed, and they
>wouldn't start.

>The error was something about unrecognized symbols or
>something in ld-elf-something. I can't be more specific, because after
>a reboot, stuff worked again - mostly.

>Now applications periodically coredump, but then start again.

>Does anyone have any insights?

There are several potential sources of problems, but to determine what
is going wrong on your system, you need to provide more information.
The error message you refer to would help, but to really narrow it
down you need to recompile the problematic software with debugging
symbols, and then attach a debugger to the coredumps:

http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/debugging.html

Our base system compiler suite is stuck at a patched version of gcc
4.2 because of licensing issues, and our base system now includes
symbol versioning, which was supposed to make updating software that
uses shared libraries easier by relying on "internal versioning" in
libraries rather than frequent changes of library major version
numbers.  For us, though, it's now causing problems, because the
Fortran-related ports have been switched over to gcc 4.4, and now want
the shared libraries from /usr/local/lib/gcc44, rather than those with
the same name, but with different internal versions, that are from the
base system, and are in /lib and /usr/lib.  This can confuse the
linker when ports use libraries built by the different compilers. The
gcc ports maintainer attempted to prevent some of these problems from
occurring by hardcoding instructions into the binaries built by gcc
4.4 that cause them to try to look in /usr/local/lib/gcc44 first, but
the fix is not perfect, and some problems many continue until we can
change our system compiler or our method of linking.  You can prevent
some of them from happening by adding entries to libmap.conf(5) that
prefer the libraries in /usr/local/lib/gcc44 to those from the base
system, because these libraries should (ideally) be
backwards-compatible.

It is also possible that you could occasionally see some strange
problems with numpy on some architectures because it was recently
discovered that it uses some floating-point handling code that doesn't
incorporate some FreeBSD fixes that handle SSE properly and prevent
some i387 registers from being overwritten.

And of course, there is always the possibility that you are mixing
stale ports with new ones, or that some of your ports are corrupt.
Make sure that your ports tree and all of your related ports are
up-to-date before spending a lot of time on debugging.

Regards,
                  b.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d873d5be0912201908v50c33e87j65798165cdd3b1d1>