troubles with ginac 1.2 on debian unstable
Hello, i was so happy about 1.2 release, that I downloaded the new 1.2 version of ginac, compiled and installed on my debian unstable machine, using usual configure, make, su, make install. I also have another ginac version 1.1.6-1 installed. When I build a simple proggy using ginac, I use new (1.2) ginac lib and the old cln: g++ -o charpoly charpoly.cpp /usr/local/lib/libginac.a -lcln The resulting program crashes with the segmentation fault. Even if it does nothing. Including <ginac/ginac.h> and compiling the empty program is enough to produce the segfault. The current installation contains the cln version 1.1.6-1. Any hints? I thought, it is because of version incompatibility between the cln library and the new ginac. Then i tried to download the newest cln, which, according to its site should be 1.1.7. But the download site ftp://ftpthep.physik.uni-mainz.de/pub/gnu/ does not contain this version... Or is it because of different compiler versions used to compile cln and my own ginac 1.2? Any ideas? Andrius Kurtinaitis
Hallo. On Wed, Mar 24, 2004 at 12:33:21PM +0200, Andrius Kurtinaitis wrote:
Hello,
i was so happy about 1.2 release, that I downloaded the new 1.2 version of ginac, compiled and installed on my debian unstable machine, using usual configure, make, su, make install. I also have another ginac version 1.1.6-1 installed.
When I build a simple proggy using ginac, I use new (1.2) ginac lib and the old cln:
g++ -o charpoly charpoly.cpp /usr/local/lib/libginac.a -lcln
The resulting program crashes with the segmentation fault. Even if it does nothing. Including <ginac/ginac.h> and compiling the empty program is enough to produce the segfault. The current installation contains the cln version 1.1.6-1.
Any hints?
I always get the same phenomenon when I compile the GiNaC library with optimization level -O3. But I am not sure where this comes from: gcc or GiNaC? Bye, Jens Vollinga
Hi, Jens Vollinga wrote:
I always get the same phenomenon when I compile the GiNaC library with optimization level -O3. But I am not sure where this comes from: gcc or GiNaC?
I believe, the ginac was compiled with -O2, not -O3. At least the generated makefiles do not contain -O3 option. Andrius
Hi. On Wed, Mar 24, 2004 at 01:00:25PM +0200, Andrius Kurtinaitis wrote:
Hi,
Jens Vollinga wrote:
I always get the same phenomenon when I compile the GiNaC library with optimization level -O3. But I am not sure where this comes from: gcc or GiNaC?
I believe, the ginac was compiled with -O2, not -O3. At least the generated makefiles do not contain -O3 option.
But the phenomenon seems to be VERY similar. So if you are confident with some changing the sources you might try to do the following: remove the deconstructor of library_init: in ex.h put comments in front of ~library_init and in utils.cpp put comments in front the definition of ~library_init (approx. lines 395-403) and recompile. Maybe the seg fault is gone then. Bye, Jens
Hi, 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 Is it some fundamental linux thing that i still do not know? Andrius Andrius Kurtinaitis wrote:
Hello,
i was so happy about 1.2 release, that I downloaded the new 1.2 version of ginac, compiled and installed on my debian unstable machine, using usual configure, make, su, make install. I also have another ginac version 1.1.6-1 installed.
When I build a simple proggy using ginac, I use new (1.2) ginac lib and the old cln:
g++ -o charpoly charpoly.cpp /usr/local/lib/libginac.a -lcln
The resulting program crashes with the segmentation fault. Even if it does nothing. Including <ginac/ginac.h> and compiling the empty program is enough to produce the segfault. The current installation contains the cln version 1.1.6-1.
Any hints?
I thought, it is because of version incompatibility between the cln library and the new ginac. Then i tried to download the newest cln, which, according to its site should be 1.1.7. But the download site ftp://ftpthep.physik.uni-mainz.de/pub/gnu/ does not contain this version...
Or is it because of different compiler versions used to compile cln and my own ginac 1.2?
Any ideas?
Andrius Kurtinaitis
On Wed, Mar 24, 2004 at 05:12:55PM +0200, Andrius Kurtinaitis wrote:
Hi, 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 Is it some fundamental linux thing that i still do not know? Andrius
AFAIK, that's some obscure g++ ABI staff. For average users (like me) it boils down to the fact that there is no simple way to build static binary from C++ source.
On Wed, 24 Mar 2004, Sheplyakov Alexei wrote:
AFAIK, that's some obscure g++ ABI staff. For average users (like me) it boils down to the fact that there is no simple way to build static binary from C++ source.
Sure there is. There is nothing that makes static C++ libraries more balky than shared libraries. Your statement only adds confusion. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hello! I am trying to build GiNaC-1.1.6 on Alpha machine running Linux. Compilation passed without any errors, but... ~/build/GiNaC-1.1.6 $ make check [huge snip] GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia................ passed examining consistency of numeric types...... passed examining power laws..... passed examining consistency of symbolic functions.... passed examining consistency of nestedsums functions.............................................................../exams.ref exams.out differ: char 240, line 10 FAIL: run_exams ~/build/GiNaC-1.1.6 $ cat check/exams.out ----------several historic failures: (no output) ----------consistency of numeric types: (no output) ----------power laws: (no output) ----------consistency of symbolic functions: (no output) ----------consistency of nestedsums functions: Internal error: statement in file real/elem/cl_R_mul.cc, line 38 has been reached!! Please send the authors of the program a description how you produced this error! I've tried to build some simple programs, some of them work fine, but most produce the same error message or just a plain segfault. Any ideas? P.S. Some info about OS, compiler, etc. OS: Debian GNU/Linux 3.0 (a.k.a "woody") g++ version: 3.0.4 CLN version: 1.1.5, was configured with: CXXFLAGS='-O2 -g -fno-exceptions' ./configure --with-gmp --prefix=~/inst GiNaC was configured with: CXXFLAGS='-O2 -g' ./configure --prefix=~/inst
Hi! 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 /home/rbk/projects/GiNaC/ginac/ptr.h:40:1160:beg:0x80dc43e (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 () (gdb) 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? ;-) Cheers -richy. PS: CLN 1.1.6 is the newest version, not 1.1.7. Sorry for the confusion. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
participants (4)
-
Andrius Kurtinaitis
-
Jens Vollinga
-
Richard B. Kreckel
-
varg＠thsun1.jinr.ru