Thread: Re: [Tecomp-user] Tecomp-user Digest, Vol 9, Issue 1
Status: Beta
Brought to you by:
helmut_brandl
From: Wolfgang J. <wj...@so...> - 2009-11-24 11:34:06
|
tec...@li... wrote: > Message: 4 > Date: Mon, 23 Nov 2009 18:21:57 +0100 > From: Wolfgang Jansen <wj...@so...> > Subject: [Tecomp-user] Installation problem > To: tec...@li... > Message-ID: <4B0...@so...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hello, > > today I downloaded Tecomp (version 0.20) for the first time > and tried to instal it at a Sun/Solaris platform. > 'gmake' issues soon the message > > g++ -O3 -Wall -DCY_ASSERTIONLEVEL_NO -I../tools > -I../../cal/src/general -I../../cal/src/container \ > -c -o../../gen_dir/obj/feature_name_o.o feature_name.cpp > /usr/ccs/bin/as: error: no input filename given > usage: /usr/ccs/bin/as [-V] [-Q{y,n}] [-q] [-s] > [-S] [-K {pic,PIC}] [-o objfile] [-L] [-T] > [-P [[-Yc,path] [-Ipath] [-Dname] [-Dname=def] [-Uname]]...] > [-m [-Ym,path]] [-n] [-ul] [-xF] > [-m32] [-m64] > > [-xarch={v7,v8,v8a,v8plus,v8plusa,v8plusb,v9,v9a,v9b,sparc,sparcvis, > sparcvis2,sparcfmaf,sparcima}] > [-xcode={pic13,pic32}] file.s... > gmake[2]: *** [../../gen_dir/obj/feature_name_o.o] Error 1 > > As I understand the message, the bug is with the "-o" option not > separated by white space from its parameter. > I did not find any related command in the various 'makefile's . > So, what can I do? > > With regards > Wolfgang Jansen > > Hello Helmut, thanks for the hint: adding a blank after all occurrences of '-o' fixed the bug. (BTW, for 20 years I have applied the '-o' option with a blank running very different C compilers. To my knowledge, the blank is forbidden only in case of the '-I' and '-L' options.) To the bigendian question: yes, I'm working an a bigendian Sun/sparc platform and, yes, the compiler does immediately crash. (sorry, for the bad news). To see what happens, I re-compiled the stuff with '-g' and '-O0' options and run the compiler under 'gdb'. The crash message, the stack trace, and the values of some variables are: Program received signal SIGSEGV, Segmentation fault. 0x000aa684 in eiffel_parse () at sequence_arrayed.h:748 748 new (p->last()) T(e); #0 0x00173bc8 in sequence_arrayed_t<unsigned long long>::extend_rear ( this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:748 #1 0x001789bc in sequence_arrayed_t<unsigned long long>::force_rear ( this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:760 #2 0x0019c9a4 in numeric_constants_t::force_rear (this=0x256d6c, val=0) at class.h:265 #3 0x000dc438 in eiffel_parse () at eiffel.y:3716 #4 0x000de330 in parse_eiffel_file (f=0x254e68, cls_to_parse=0x256d40, f_name=0x25d434 "./fahr_celsius.e", col=0x254810) at eiffel.y:4275 #5 0x000cdea0 in eiffel_system_t::parse_system (this=0x254810) at eiffel_system.cpp:239 #6 0x0009be54 in main (argc=2, argv=0xffbfdf4c) at tecomp.cpp:188 p = {el_sz = 8, el_sz_al = 8, cnt = 1, cap = 10} e = 0 c0 = 1068848469 = 0x3fb55555 *(float*)&c0 = 1.41666663 *(double*)&c0 = 0.083333333333333329 I'm sure that assigning of 'c0' did work correctly, but I don't have any idea where the first error is. WJ -- Dr. Wolfgang Jansen University of Potsdam, Germany Institute of Computer Science Tel: +49 331 / 977 3047 mailto: wj...@so... |
From: Helmut B. <hel...@gm...> - 2009-11-24 15:13:50
|
Wolfgang Jansen wrote: > Hello Helmut, > > thanks for the hint: adding a blank after all occurrences > of '-o' fixed the bug. > (BTW, for 20 years I have applied the '-o' option with a blank > running very different C compilers. To my knowledge, the blank > is forbidden only in case of the '-I' and '-L' options.) Ok, I have already changed the svn repository. So in the next release tecomp will have a blank between the -o option and the filename. > > To the bigendian question: > yes, I'm working an a bigendian Sun/sparc platform > and, yes, the compiler does immediately crash. > (sorry, for the bad news). > To see what happens, I re-compiled the stuff with > '-g' and '-O0' options and run the compiler under 'gdb'. Thanks for the stacktrace. I am not yet sure what is going on here. Obviously the "count" method of seq_arr_inter_t returns a completely screwed up value. This is strange, because your stacktrace says, that the attribute "cnt" has the meaningful value "1", and the "count" method just calls then "count" method of seq_arr_intern_t which just returns the value of the attribute "cnt". If you run your compiled system in gdb, you could see, what count() and p->count() return at the location of the segfault. And you can see the pointer values of p and p->last(). The 2 pointers should be just a couple of bytes apart. Some other remarks: There is no need to change the compiler flags. If you issue make atecomp you get a compiler named atecomp in gen_dir/bin which has all debugging facilities and all assertions in the compiler enabled. I don't know what you did exactly. But better use atecomp for debugging (then I know better what you have done and can compare it with the results on my machine). The advantage of atecomp is that it is heavily asserted and might throw an assertion which give us a better hint on what is going on there. If you edited some CFLAGS please restore the original values and use atecomp instead. And before any recompilation, delete all files in gen_dir/obj. There are some lower level tests. E.g. cd cal/test/container make test tests all the used containers in tecomp. If this test fails, debugging is easier. Regards Helmut > The crash message, the stack trace, and the values > of some variables are: > > Program received signal SIGSEGV, Segmentation fault. > 0x000aa684 in eiffel_parse () at sequence_arrayed.h:748 > 748 new (p->last()) T(e); > > #0 0x00173bc8 in sequence_arrayed_t<unsigned long long>::extend_rear ( > this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:748 > #1 0x001789bc in sequence_arrayed_t<unsigned long long>::force_rear ( > this=0x256d6c, e=@0xffbfb4a0) at sequence_arrayed.h:760 > #2 0x0019c9a4 in numeric_constants_t::force_rear (this=0x256d6c, val=0) > at class.h:265 > #3 0x000dc438 in eiffel_parse () at eiffel.y:3716 > #4 0x000de330 in parse_eiffel_file (f=0x254e68, cls_to_parse=0x256d40, > f_name=0x25d434 "./fahr_celsius.e", col=0x254810) at eiffel.y:4275 > #5 0x000cdea0 in eiffel_system_t::parse_system (this=0x254810) > at eiffel_system.cpp:239 > #6 0x0009be54 in main (argc=2, argv=0xffbfdf4c) at tecomp.cpp:188 > > p = {el_sz = 8, el_sz_al = 8, cnt = 1, cap = 10} > e = 0 > c0 = 1068848469 = 0x3fb55555 > *(float*)&c0 = 1.41666663 > *(double*)&c0 = 0.083333333333333329 > > I'm sure that assigning of 'c0' did work correctly, > but I don't have any idea where the first error is. > > WJ > |