Re: Branch Version_2_7_0pre

[Kirill A. Korinsky]

Hello,

On 24. Dec 2023, at 15:13, Camm Maguire <camm@maguirefamily.org> wrote:

Greetings!

"Kirill A. Korinsky" <kirill@korins.ky> writes:

May we ban gprof on macOS completley?

I'd rather not as some may use gcc and want to try it out.

This is the code that is supposed to automatically disable gprof where
not supported, is it only working on some machines for you?

  OLD_CFLAGS=$CFLAGS
  if ! add_arg_to_cflags -pg ; then GPROF="" ; fi
  CFLAGS=$OLD_CFLAGS
  AC_MSG_CHECKING([working gprof])
  if test "$GPROF" = "" ; then
      AC_MSG_RESULT([disabled])
  else
      AC_MSG_RESULT([ok])
      AC_DEFINE(USE_GPROF,1,[use gprof])
  fi

yes, this code decided that gprof works but I haven't found any trace of _mcleanup function in macOS SDK: https://github.com/search?q=repo%3Aphracker%2FMacOSX-SDKs%20_mcleanup&type=code

Anyway, I suggest to ignore this for now.

3. Unfortunately system's gcc / ld is too old, so old that it doesn't support -no_pie this can be excluded by patch like this:

Just FYI, gcl absolutely needs -no-pie, and in fact tries to add
-fno-PIC -fno-pic -fno-PIE -fno-pie as well.  On older gcc, this was the
default even when the -no-pie option was absent, so those configurations
should be useable as well.  Here is the code that adds flags when
available but proceeds without when absent:

add_args_to_cflags  -fsigned-char -pipe -fcommon \
                   -fno-builtin-malloc -fno-builtin-free \
                   -fno-PIE -fno-pie -fno-PIC -fno-pic \
           -Wall \
           -Wno-builtin-requires-header -Wno-empty-body -Wno-self-assign \
           -Wno-unused-but-set-variable

add_args_to_ldflags -no-pie # -Wl,-z,lazy

This will lead to problems only when pic/pie is the default *and* there
is no option to turn it off.  SIGILL and the like are likely symptoms.

Just double checking that you see

   AC_MSG_RESULT([emulating sbrk for mac]);

in all your configure output.  If you get a build without it that is
even better, but mac could not unrandomize sbrk for quite a while in the
past.  It does look like your environment has the personality support to
do it though, and might be worth a try once things have stabilized.

agreed, let ignore this as well.

4. So, I've decided to ban system's compiler. MacPorts uses clang by default which lead  to an issue:
# ld: illegal text-relocation to ___stack_chk_guard in /usr/lib/libSystem.dylib from _emsg in ...

Somewhere here I feel that ban clang as well right now isn't bad idea :)

I would not give up on clang over this.  References to
___stack_chk_guard are completely optional and goverened by the
NEED_STACK_CHK_GUARD define in your config.h.  I thought it was absent
on the mac anyway.

5. So, it had compiled suceffuly by GCC-7 which lead to the issue:

grep: raw_pre_gcl_map: No such file or directory
touch raw_pre_gcl_map
/opt/local/bin/gcc-mp-7 -Wl,-headerpad_max_install_names -L/opt/local/lib -lMacportsLegacySupport -arch i386 -no-pie -Wl,-no_pie -m32 -Wl,-headerpad,56 -o raw_pre_gcl   -L.   -lpre_gcl `echo -lm  -lgmp -lreadline | sed -e 's/-lncurses/ /'` -lc -lgclp
cp init_raw.lsp foo
echo "(unless si::*quit-tags* (in-package \"USER\")(system:save-system \"saved_pre_gcl\"))" >>foo
ar x libpre_gcl.a $(ar t libpre_gcl.a |grep ^gcl_)
/opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/unixport/raw_pre_gcl
/opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/unixport/ -libdir
/opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/ < foo
/bin/sh: line 1: 25726 Illegal instruction     /opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/unixport/raw_pre_gcl
/opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/unixport/ -libdir
/opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/ < foo
make[1]: *** [saved_pre_gcl] Error 132

which probably the same that I've investigated in different thread.

Just noticing that mainline gcc is up to -13 on linux systems.  Is this
available?

Barring some incompatibility of that sort, this could be caused by a
faulty sbrk.  Any way to get the same environment as on the successful
x86_64?

x86_64 uses clang and it's available via MacPorts and works reasonable well on this machine. Reasonable means that I discovered only one edge case with ECL and BhoemGC when it doesn't work :) and I've suceffuly build clang / llvm by using that clang / llvm.

Here I've attached config.log which contains the failure by using clang to build it. 

-- 
wbr, Kirill

config.log
Description: Binary data

signature.asc
Description: Message signed with OpenPGP