HTCondor Project List Archives



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Condor-devel] Debain port showstopper



Hello,

I have determined that the proposed full port of Condor to Debain 4.0 head
(updated from 3/1/07) is broken and cannot be checked in yet.

The problem concerns itself with gcc's 4.1.2 C++ exception handling
runtime and glibc 2.3.2.27.9.7--which we build and link against for
stduniv jobs.

Basically, C++ exceptions as they currenty stand are broken in
stduniv. This is due to the gcc's 4.1.2 C++ runtime assuming that the
glibc it will be linking against was compiled with thread local storage,
which our glibc is not (whereas the system glibc was). This causes a
segmentation fault when an exception is thrown.

gcc's 4.1.2 C++ runtime exeption handling code is detailed here:

http://www.google.com/codesearch?hl=en&q=+_GLIBCXX_HAVE_TLS+show:UvBZTAA1Xl8:5DJndYSvOaQ:1q4zbmUr0x4&sa=N&cd=3&ct=rc&cs_p=ftp://glug-nith.org/tarballs/gcc-g%2B%2B-4.1.0.tar.bz2&cs_f=gcc-4.1.2/libstdc%2B%2B-v3/libsupc%2B%2B/eh_globals.cc#a0

The offending function which segfaults is
__gnu_internal::get_global(). This implies that _GLIBCXX_HAVE_TLS is
nonzero. Via the debugger, it looks like a segment register known to
be used for TLS (%gs) is being accessed, and is most likely not setup
properly in our nonTLS glibc, causing the segfault.

For unknown reasons, compilation of our glibc with --with-tls enabled
on the configure line results in non-compilation of the glibc with
unresolved symbols when linking ncsd.

This problem must be resolved, while keeping the constraint of utilizing
the default compiler for Debian 4.0 and not enabling glibc threading
(there must always be one thread of execution only), before this full
port is considered done.

I have made some changes to the original port by Guillaume Pernot, and if
he would like to work on this port, can feed him back the new codebase.

Thank you.

-pete