Greetings! "Chun Tian (binghe)" <binghe.l...@gmail.com> writes:
> Greetings, and thanks always for your kind help. > > With your fixes of replacing (ufixnum) to (fixnum) in the two vs_push > lines in gbc.c, now with the default optimizations (i.e. no more -O0) > the building process doesn't crash any more! I hope this patch, if it's > indeed reasonable, can be made official and also on GCL 2.6.14 branch. > And let me know if you still want to see the compilation warnings of > gbc.c, either before or after this changes. > Yes to both, i.e. I will commit this patch, and please give me the compiler output on the original files. In fact, I would like to see the entire configure and make output on the existing commit to the point of crash posted if you do not mind. > Now I directly reached the issue mentioned in the other email, i.e. when > executing "saved_pre_gcl", the following unrecoverable error happens: > > symbol not found in flat namespace '_Cnil_body' > > There are a lot of compilation warnings talking about function > declaration without prototypes: >> In file included from read.d:28: >> In file included from ../h/include.h:127: >> ../h/../h/att_ext.h:68:8: warning: a function declaration without a > prototype is deprecated in all versions of C and is treated as a > zero-parameter prototype in C2x, conflicting with a previous declaration > [-Wdeprecated-non-prototype] >> double big_to_double(); >> ^ >> ../h/../h/compprotos.h:6:8: note: conflicting prototype is here >> double big_to_double(object); >> ^ > Much but perhaps not all of this can be cleaned up. The compiler output requested above should help here. > I can guess the following reasons: > > 1. When you call "gcc" (actually clang) on C code with "*.d" extension > names, clang wrongly recognized the input code as C++, and then has > followed C++ standards to treat symbol names. This is not the case, as .d is pre-processed into .c before passing to the C compiler. > 2. Under C++ environment assumptions, the prototype declarations without > arguments have been wrongly treated as different (C++) functions. > This may be the case. What I suspect is that linking a -no-pie raw executable might imply some different standard than that implied by compiling a conventional shared library. What is the current gcc status for you? Take care, -- Camm Maguire c...@maguirefamily.org ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
