You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using 64-bit addressing (by passing -Duse64bitall to Configure) on macOS arm64, clang throws the following cryptic error when compiling a test program:
Use which C compiler? [cc]
clang: error: invalid arch name '-arch -B/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gcc'
clang: error: invalid arch name '-arch -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk'
Uh-oh, the C compiler 'cc' doesn't seem to be working.
'cc' ' -fno-common -DPERL_DARWIN -mmacosx-version-min=11 -arch -B/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gcc -B/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib/gcc -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -mmacosx-version-min=11' ' -mmacosx-version-min=11 -arch -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk'
The first commit is to handle the arm output from uname -p and respectively to pass the proper architecture - arm64 right after the -arch flag that would otherwise be dangling.
Just in case some time in the future Apple introduces a yet another CPU architecture to their Mac devices, I decided to add an extra exit 1 with the second commit so that the Configure error would be the last thing that is displayed to the user. This way, we don't see the cryptic clang error:
Which of these apply, if any? [darwin]
Adding -mmacosx-version-min=10.14 to ccflags
Adding -mmacosx-version-min=10.14 to ldflags
*** Don't recognize processor, can't specify 64 bit compilation.
After the second commit is added, the following Configure output that I saw before went missing:
Configure uses the operating system name and version to set some defaults.
The default value is probably right if the name rings a bell. Otherwise,
since spelling matters for me, either accept the default or answer "none"
to leave it blank.
Operating system name? [darwin]
Operating system version? [24.0.0]
By default, perl5 will be installed in /Users/mtsan/perl/gen/out/bin, manual pages
under /Users/mtsan/perl/gen/out/man, etc..., i.e. with /Users/mtsan/perl/gen/out as prefix for all
installation directories. Typically this is something like /usr/local.
If you wish to have binaries under /usr/bin but other parts of the
installation under /usr/local, that's ok: you will be prompted
separately for each of the installation directories, the prefix being
only used to set the defaults.
Installation prefix to use? (~name ok)
[/Users/mtsan/perl/gen/out]
AFS does not seem to be running...
In some special cases, particularly when building perl5 for distribution,
it is convenient to distinguish the directory in which files should be
installed from the directory (/Users/mtsan/perl/gen/out) in which they will
eventually reside. For most users, these two directories are the same.
What installation prefix should I use for installing files? (~name ok)
[/Users/mtsan/perl/gen/out]
Perl can be built to offer a form of threading support on some systems
To do so, Configure can be run with -Dusethreads.
Note that Perl built with threading support runs slightly slower
and uses slightly more memory than plain Perl.
If this doesn't make any sense to you, just accept the default 'y'.
Build a threading Perl? [y]
(Your platform does not have any specific hints for threaded builds.
Assuming POSIX threads, then.)
Perl can be built so that multiple Perl interpreters can coexist
within the same Perl executable.
This multiple interpreter support is required for interpreter-based threads.
Use which C compiler? [cc]
Personally, I believe that this is a good tradeoff. If Configure can't do better but pass a dangling -arch flag, then maybe it is a good idea to exit as early as possible so that the user can either add a hint for their CPU architecture (and then create a PR here like I did) or just call Configure without 64-bit addressing. However, if any of the reviewers think that this is something that should not be done, I'll be fine with reverting the second commit.
This set of changes does not require a perldelta entry.
When calling Configure with use64bitall on arm64 macOS, it compiles a test program using clang and an -arch flag that is not followed by anything. Seems like the darwin arch hint when using use64bitall couldn't work with the 'arm' result from uname -p.
Not sure if Apple are to introduce another CPU architecture to their device lineup - but they already did it 2 times. When building this on arm64 macOS, before adding the arm64 arch hint, Configure with use64bitall wouldn't exit, but a rather cryptic clang error would be thrown for an unknown arch name, simply because nothing was passed after the -arch flag.
@jkeenan, thanks for approving the test pipeline run. I addressed the failing updateAUTHORS test. Could you please approve the workflow again?
I'd greatly appreciate it if someone could merge the PR after the tests pass :) Manually patching the darwin hints to build perl for my application is causing some trouble. It'd be great to have an official perl release to use with this fix.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When using 64-bit addressing (by passing
-Duse64bitall
to Configure) on macOS arm64, clang throws the following cryptic error when compiling a test program:The first commit is to handle the
arm
output fromuname -p
and respectively to pass the proper architecture -arm64
right after the-arch
flag that would otherwise be dangling.Just in case some time in the future Apple introduces a yet another CPU architecture to their Mac devices, I decided to add an extra
exit 1
with the second commit so that the Configure error would be the last thing that is displayed to the user. This way, we don't see the cryptic clang error:After the second commit is added, the following Configure output that I saw before went missing:
Personally, I believe that this is a good tradeoff. If Configure can't do better but pass a dangling
-arch
flag, then maybe it is a good idea to exit as early as possible so that the user can either add a hint for their CPU architecture (and then create a PR here like I did) or just call Configure without 64-bit addressing. However, if any of the reviewers think that this is something that should not be done, I'll be fine with reverting the second commit.This set of changes does not require a perldelta entry.