bugGNU Common Lisp - Bugs: bug #63875, Build failure on Apple Silicon Macs


bug #63875: Build failure on Apple Silicon Macs

Submitter:  Ryan Carsten Schmidt <ryandesign>
Submitted:  Mon 06 Mar 2023 10:52:24 PM UTC
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Sun 28 Jan 2024 02:18:13 PM UTC, comment #1: 

Greetings, and thanks for your report!  We would greatly prefer to use sbrk if possible, but when this section of configure was last written, macos could not unrandomize sbrk via the personality mechanism.  This is essential, hence the emulation put in for macosx.  If you find this situation has changed, please let me know.  Please feel free to add the #include <unistd.h> to configure.in then run autoconf, or make sure -Werror is not in CFLAGS.  This will be cleaned up in next release.

Camm Maguire <camm>
Group administrator
Mon 06 Mar 2023 10:52:24 PM UTC, original submission:  

gcl 2.6.12 fails to build on Macs with Apple Silicon (ARM) processors. This was reported to MacPorts here:


Running the configure script ends with this error:

checking for sbrk... yes
checking for ADDR_NO_RANDOMIZE constant... no assuming 0x40000
checking for ADDR_COMPAT_LAYOUT constant... no
checking for ADDR_LIMIT_3GB constant... no
checking for personality(ADDR_NO_RANDOMIZE) support... no
checking that sbrk is (now) non-random... cannot trap sbrk

config.log shows the immediate reason is:

configure:6830: checking that sbrk is (now) non-random
configure:6849: /usr/bin/clang -o conftest -pipe -Os -std=gnu89 -fno-pie -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64  -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -fno-pie -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64 conftest.c  >&5
conftest.c:44:19: error: implicit declaration of function 'sbrk' [-Werror,-Wimplicit-function-declaration]
1 error generated.

So you are trying to use `sbrk` without including the <unistd.h> header where it's defined, and you should fix that.

However the configure script deliberately prevents the use of `sbrk` on Intel Macs:


The description of `sbrk` from its manpage on macOS begins by saying:


> The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management.

And that manpage is dated December 1993, over 7 years before the first Unix-based macOS shipped. It makes me wonder why you prevent the use of `sbrk` only on Intel macOS. At the time, Intel and PowerPC were the only processor families macOS ran on. Was there a reason why you wanted to use `sbrk` on PowerPC Macs? It seems liklier to me that you should prevent the use of `sbrk` on macOS generally regardless of processor family. Perhaps you shouldn't even be using `sbrk` on any OS. (Or do you still care about supporting systems that were already considered historical curiosities back in 1993?)

I cannot test gcl 2.6.13 or 2.6.14 because they do not build at all (see bug #63844) but checking the git repository I didn't see any changes to the conditions for the use of `sbrk` so I assume the issue has not yet been fixed.

Ryan Carsten Schmidt <ryandesign>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by camm (Posted a comment)
  • -email is unavailable- added by ryandesign (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code