troubles with ginac 1.2 on debian unstable

Richard B. Kreckel kreckel at
Thu Mar 25 00:39:09 CET 2004


On Wed, 24 Mar 2004, Andrius Kurtinaitis wrote:
> I just tried to link with the shared ginac library instead of static and
> it worked:
> g++ -o charpoly charpoly.cpp -L /usr/local/lib -lginac -lcln

Confirmed.  It segfaults immediately when GiNaC is linked statically.

I don't think that the version of CLN is to blame.  If I take
libcln3_1.1.6-1 on a Debian/sarge system and libginac-dev_1.1.5-1 the
phenomenon disappears.  So the problem must be with GiNaC 1.2.

Also, the optimization level you compile your main program with can't
realistically make any difference.

Here is a quick shot at the problem using gdb:

Program received signal SIGSEGV, Segmentation fault.
GiNaC::function_options::initialize() (this=0xbffff9e0) at ptr.h:40
(gdb) bt
#0  GiNaC::function_options::initialize() (this=0xbffff9e0) at ptr.h:40
#1  0x080dc00f in function_options (this=0xbffffa34, n=@0x0, tn=@0x0) at function.cpp:58
#2  0x081776b8 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at stl_alloc.h:652
#3  0x081785c4 in _GLOBAL__I__ZN5GiNaC37_GLOBAL__N_inifcns_nstdsums.cpp9xRtwb2XnE () at container.h:130
#4  0x081bf605 in __do_global_ctors_aux ()
#5  0x0804d6b9 in _init ()
#6  0x081bf53b in __libc_csu_init ()

That symbol in #3 demangles to a "global constructors keyed to
GiNaC::(anonymous namespace)::Xn".  Ahhh...

I'm way too tired to see the static initialization order fiasco right now.
Jens?   ;-)


PS: CLN 1.1.6 is the newest version, not 1.1.7.  Sorry for the confusion.
Richard B. Kreckel

More information about the GiNaC-list mailing list