Re: macOS building issues after dc9eba0760dedcd3d042a408e715b38ac2222aa3

[Chun Tian (binghe)]

Greetings,

Please find in attach three log files. My GCC (clang) information is the
following (Note that it's impossible to get more info like 'gcc -v' with
a real GCC compiler):

binghe@binghe-mac7:~/Lisp/gcl/gcl$ gcc -v
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.3.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

The "configure.log" is generated by the following commands in GCL
working directory (with the unmodified 'master', commit id: 22c93c4c)

export C_INCLUDE_PATH=/opt/local/include
export LIBRARY_PATH=/opt/local/lib

./configure --prefix=/usr/local \
      --disable-notify \
      --disable-statsysbfd \
      --disable-ansi \
      --enable-custreloc \
      --enable-emacsdir=/opt/local/share/emacs/site-lisp/gcl \
      --enable-infodir=/opt/local/share/info \
      --enable-readline \
      --disable-gprof \
      --without-x \
      --disable-xgcl \
      --disable-tcltk \
      --enable-dynsysgmp \
      --enable-debug > configure.log

Then I found there's another "config.log" with more information (about
my building environment), so I attached it too. (The file is 4MB big, so
I compressed it by bzip2).

Then I call make and redirected all std and error outputs to "make.log":

binghe@binghe-mac7:~/Lisp/gcl/gcl$ make >& make.log

The building process stopped at the previous mentioned linking issue
"symbol not found in flat namespace '_Cnil_body'".

Unfortunately, I can't see any special compiler warnings about the
fixnum/ufixnum issue.  More importantly, the previous observed crash
disappeared, even without your proposed code changes! (I think this
means the crashing is sensitive to particular memory layout, or due to
memory leaking, thus not always reproducible.)

Hope this helps...

P.S. I think I can provide you a remote access to a macOS Sonoma virtual
machine that you can connect to its desktop by VNC. (We can talk more
about this in private communications.)

Chun

On 13/02/24 00:43, Camm Maguire wrote:
> 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,
>

configure.log
Description: Text document

make.log.bz2
Description: BZip2 compressed data

config.log
Description: Text document

signature.asc
Description: OpenPGP digital signature