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:

https://trac.macports.org/ticket/67014

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]
                        fprintf(f,"%u",sbrk(0));
                                       ^
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:

http://git.savannah.gnu.org/cgit/gcl.git/commit/gcl/configure.in?h=Version_2_6_12&id=0cbc999eadb551a0e9fb36cade520cbec24188bd

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

https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/sbrk.2.html

> 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:
   
   
Comment:
   

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