Re: Branch Version_2_7_0pre

"Kirill A. Korinsky" <[email protected]> Sun, 24 Dec 2023 15:30:26 +0100
Newsgroups	gmane.lisp.gcl.devel
Message-ID	<[email protected]>
Hello,

> On 24. Dec 2023, at 15:13, Camm Maguire <[email protected]> wrote:
> 
> Greetings!
> 
> "Kirill A. Korinsky" <[email protected]> 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 <https://github.com/search?q=repo:phracker/MacOSX-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
signature.asc (application/pgp-signature, 833 B)