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

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