Re: [Gcl-devel] GCL 2.6.11 on Mac OS X Yosemite

[Camm Maguire]

Greetings!

Gabriel Dos Reis <address@hidden> writes:

> Camm:
>
> Lawrence fixed the Macports port of GCL-2.6.12 so I was able to install it.
>

Great!  How?

> The next thing, though, is that GCL appears not to be work properly with 
> Clang on this platform -- Clang is the default system compiler on new
> versions on Mac OS X.
>
> For example, I tried to build OpenAxiom with it, but was stumped by:
>
> Finished compiling core.lisp.
>
> gcl \
>
> -eval '(load "core")' \
>
> -eval '(|AxiomCore|::|link| "base-lisp" (quote nil) 
> "|AxiomCore|::|topLevel|")'
>
> Unrelocated non-local symbol: ___stack_chk_fail
>

This is due to a cflag mismatch.  For example, on Debian, by policy, gcl
is built with

"gcc -c -fstack-protector-strong -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2  -Wall -fsigned-char -Wno-unused-but-set-variable
-pipe "

All modules (to be loaded) should be built with the same flags.  My
guess here is that the module had the stack protector, but not the
default gcl build.

Note also that there is a config.h define NEED_STACK_CHK_GUARD which
might be necessary.

> Error: 
>
> Fast links are on: do (si::use-fast-links nil) for debugging
>
> Signalled by LOAD.
>
> Condition in LOAD [or a callee]: INTERNAL-SIMPLE-ERROR: The assertion 
> !fprintf(stderr,"Unrelocated non-local symbol: %s\n",st1+n->n_un.n_strx) on
> line 147 of 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcl/gcl/work/gcl/o/
> sfaslmacho.c in function relocate_symbols failed
>
> Broken at LOAD.  Type :H for Help.
>
>     1  Return to top level. 
>
>>>
>
> Clang is also unhappy that GCL is declaring standard C functions instead of 
> including the appropriate headers, plus some other stylistic issues:
>
> ; Note: Tail-recursive call of |processCommandLine| was replaced by iteration.
>
> ;; Note: Tail-recursive call of |processCommandLine| was replaced by 
> iteration.
>
> ;; Note: Tail-recursive call of |processCommandLine| was replaced by 
> iteration.
>
> ;; Note: Tail-recursive call of DO-IMPORT-MODULE was replaced by iteration.
>
> End of Pass 2.  
>
> core.c:765:5: warning: declaration of built-in function 'setjmp' requires
>
>       inclusion of the header <setjmp.h> [-Wbuiltin-requires-header]
>
> int setjmp();
>
>     ^
>
> core.c:766:5: warning: declaration of built-in function '_setjmp' requires
>
>       inclusion of the header <setjmp.h> [-Wbuiltin-requires-header]
>
> int _setjmp();
>
>     ^
>
> core.c:779:71: warning: for loop has empty body [-Wempty-body]
>
>   {char i;for (i=0;i<sizeof(x)*8 && !((x>>(sizeof(x)*8-1-i))&0x1);i++); 
> return i;}
>
>                                                                       ^
>
> core.c:779:71: note: put the semicolon on a separate line to silence this
>
>       warning
>
> core.c:783:55: warning: for loop has empty body [-Wempty-body]
>
>   {char i;for (i=0;i<sizeof(x)*8 && !((x>>i)&0x1);i++); return i;}
>
>                                                       ^
>
> core.c:783:55: note: put the semicolon on a separate line to silence this
>
>       warning
>
> 4 warnings generated.
>
> I know you worry about including standard headers, but the world is moving in 
> that direction...
>

Yes, these warnings appear harmless, and for now might be turned off
with -Wno-... There's nothing really bad about standard headers except
they defeat the purpose of the pre-compiled header shipped with gcl for
gcc performance reasons.  setjmp's jmp_buf in particular is a char
array (aligned) in gcl, and I can't see us changing this immediately.
Might be good to revisit this during the next release cycle, though.

Please let me know if problems persist in getting an open axiom build.

Take care,

> -- Gaby
>

-- 
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah