Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3

[Camm Maguire]

Greetings!

"Chun Tian (binghe)" <binghe.lisp@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                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah