Re: Branch Version_2_7_0pre

[Camm Maguire]

Greetings!

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

> Status update on i386:
>
> 1. ./configure had passed
>

Great!

> 2. gprof was enabled by default again which lead to
>
> Undefined symbols for architecture i386:
>   "__mcleanup", referenced from:
>       _fSmcleanup in libpre_gcl.a(gprof.o)
>       _gprof_cleanup in libpre_gcl.a(gprof.o)
> ld: symbol(s) not found for architecture i386
>
> 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


> 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.

>
> --- configure.in
> +++ configure.in
> @@ -341,7 +341,9 @@ case $use in
>      386-macosx)
>  # assert_arg_to_cflags -Wno-error=implicit-function-declaration
>  add_arg_to_cflags -Wno-incomplete-setjmp-declaration
> - assert_arg_to_ldflags -Wl,-no_pie
> + if test "$build_cpu" != "i386" ; then
> +   assert_arg_to_ldflags -Wl,-no_pie
> + fi
>  if test "$build_cpu" = "x86_64" ; then
>     assert_arg_to_cflags -m64
>     assert_arg_to_ldflags -m64
>
> anyway, it leads to an error:
>
> grep: raw_pre_gcl_map: No such file or directory
> touch raw_pre_gcl_map
> /usr/bin/gcc-4.2 -std=gnu99 -Wl,-headerpad_max_install_names -L/opt/local/lib 
> -lMacportsLegacySupport -arch i386 -no-pie -m32 -Wl,-headerpad,56 -o 
> raw_pre_gcl   -L.   -lpre_gcl `echo -lm  -lgmp -lreadline | sed -e 
> 's/-lncurses/ /'` -lc -lgclp
> ld: absolute addressing (perhaps -mdynamic-no-pic) used in _Llower_case_p 
> from ./libpre_gcl.a(character.o) not allowed in slidable image. Use 
> '-read_only_relocs suppress' to enable text relocs
> collect2: ld returned 1 exit status
> make[1]: *** [raw_pre_gcl_map] Error 1
> make[1]: Leaving directory 
> `/opt/local/var/macports/build/_Volumes_SharedFolders_Home_src_macports-ports_lang_gcl/gcl-devel/work/33a195d5cec2a7f8f563e11c0f1a3011ea0b30a0/gcl/unixport'
> make: *** [unixport/saved_pre_gcl] Error 2

As mentioned above, it should be clear now why pic/pie in core gcl code
will not work.

>
> 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? 

Take care,
-- 
Camm Maguire                                        camm@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah