hints/darwin.sh: skip ldflags in lddlflags #23227
Conversation
It has not effect. "adopting flags from ldflags is supposed to happen in Configure, not in hints." - leont Configuring a build of perl with -Aappend:ldflags=" -L/var/empty" and checking the output of 'perl -V:ldflags -V:lddlflags' shows ldflags=' -L/var/empty'; lddlflags='-bundle -undefined dynamic_lookup -L/var/empty'; Found when analysing issue Perl#9437 Tested on OS X 10.4 aka Darwin 8.
These macros suffixed with 'x' are guaranteed to evaluate their arguments just once. Prior to this commit, they used PL_Sv to accomplish that. But since 1ef9039 in 5.37, the macros they call only evaluate their arguments once, so the PL_Sv is superfluous.
|
Introduces a bunch of link warnings, from github builds: locally: |
|
Just as a test, can you try the following patch locally? |
The latest MacOS release has locales that set this wrongly. This isn't the first time this has been a problem. Add a debugging line that can easily be enabled to check for problems that may arise in the field.
v5.41.7-43-gcdbed2a40e introduced the OP_SUBSTR_LEFT op,
which is an optimised version of OP_SUBSTR for when the offset
is zero and the replacement string is missing or ''.
Unfortunately the deparsing for this OP missed out the closing
parenthesis when the replacement string wasn't present; i.e.:
substr($lex, 0, 4);
deparsed as:
substr($lex, 0, 4;
The fix is trivial.
Add a couple of recently-added test files to
Porting/deparse-skips.txt
These two test files have
use utf8;
"some string with accented chars"
and the accented char gets deparsed wrongly at the moment.
So skip those test files under
cd t; ./TEST -deparse
|
That didn't improve matters, nor did adding it further down as well: Configure reported it added it: but it didn't end up in config.sh: Tested with after |
|
Thanks for checking. I'll dig a bit more over the next couple of days & report back. |
So it can be appended, otherwise it just hardcodes lddlflags="-bundle -undefined dynamic_lookup" Make sure MACOSX_DEPLOYMENT_TARGET is added to $lddlflags.
Need to be explicit with OS' for macOS 11 and up here. Otherwise: Unexpected MACOSX_DEPLOYMENT_TARGET=11
Unless MACOSX_DEPLOYMENT_TARGET is passed into the build, just ride the defaults of the OS' toolchain. This code assumes OS X versioning (10.15.x ) and tries to drop the patch version from the product version so that you're targetting macOS 10.15, rather than 10.15.1. Unfortunately with macOS 11 and up, it ends up targetting the patch version and since we're no longer appending $ld to $lddlflags we end up with the core targetting the major version and the modules targetting the patch version. Resulting in warnings ld: warning: object file (/Users/runner/work/perl5/perl5/cpan/Compress-Raw-Bzip2/Bzip2.o) was built for newer 'macOS' version (14.7) than being linked (14.0)
|
I think we're good now. The only warning from the linker is I looked into into and it looks like the warning was added sometime after macOS 10.15 (macOS 11?) but I don't have anything running macOS 11 to 13 in order to point to the specific version. |
|
Built with Tested this patch on OS X 10.4/i386 shouldn't have affected anything there since Tested on macOS 10.15/x86_64. Built successfully & test passed. No warnings from linker. Tested on macOS 10.15 with
During the configure stage,
When running the test suite I suspect these are bugs in the tests, which this change has brought to light, rather than fallout due to the change. |
Is there an open ticket for this? |
There's mattn/p5-Devel-CheckLib#40 |
|
But ExtUtils::MakeMaker needs a bug report too. It's not just Devel::CheckLib which creates breaks targeting 10.4 and older. |
…ses" - `use re 'strict` -> `use re 'strict'` - delete/add some commas - link `use locale` to locale.pm
0.035 2025-05-01 11:35:41+02:00 Europe/Berlin
- regex_sets no longer experimental
- switch/smartmatch were deprecated then undeprecated
- Properly handle the win32_perlio warning
…mple. Updates from PTS 2025 to clarify how the perl disclosure process will work. * Clarify what an embargo period is as this is surprisingly not well documented on the internet. * Provide a simple walkthrough to show a real example of the process.
This improves the code in two ways: 1. Considering strict::bits is used by B::Deparse and vars.pm as unofficial API, the function having this side effect is arguably a latent bug even if it doesn’t break those callers. 2. It is harder to follow the intended logic when the function modifies $^H itself but also returns a value for the caller to apply to $^H.
Blead version was updated in March.
These entries apply also to arrays.
It is not good form to have links in the middle of a section go back to the top of that very section. Someone clicks on it, thinking they are going to get more detail or a different explanation, and all that happens is they lose their place in the section.
The documentation for doing these operations on arrays was added at a later time to the documentation onf hashes. This cleans up some awkwardness and adds an example. Fixes Perl#17719
The desired value has already been cached under a different name.
Supercedes Perl#23268, which didn't really get to the core problem. These were generating uninitialized variable warnings on OpenBSD, due to the reference existing, but the array being empty.
|
Should this go in 5.42? |
See Perl#18995 This commit just adds a simple test that IV is large enough to hold a pointer; something we claim is true, but didn't actually guarantee.
This generates a few errors on EBCDIC, which could be fixed; but it is not currently used there.
With 9e9b2f9, Configure guarantees an IV can hold a pointer. But it may be larger. This commit takes Tony Cook's suggestion about extra wording. This fixes Perl#18995
This was going to cover more, but it turned out to already be fairly well covered.
Pod::Simple's entry for $VERSION in Maintainers.pl is now in synch with what's on CPAN. We no longer need the corrective applied in 6ea7dac.
Yes please, but I suspect that question was not intended for me :) |
|
I think this should go in to 5.42. We are going to have another dev release, and this seems low risk. Based on what I understand about the change, the new version looks more correct. I would hope that an issue in ExtUtils::MakeMaker can also be filed and fixed. |
I'm trying put together an example Makefile for DBD::mysql which fixes its bundle by overriding what's in place by default, to call |
The modern way to change UTF-8 to its component bytes is to use utf8::encode Some of the tests are making sure that those component bytes aren't mistaken for being UTF-8. What those component bytes are is not actually relevant, but the tests were looking at the specific expected values of them. The problem is that these differ on EBCDIC vs ASCII platforms. Several commits had been added to try to get the correct values on both types, but EBCDIC still was getting failures. And, there is no need to test for the specific values of these irrelevant bytes. What is important is that they were not misinterpreted as if they were UTF-8. This commit goes back to the original tests before those other commits were added, and changes the matching pattern to not look for the specific irrelevant byte values. Doing so makes the tests pass on both types of platforms.
Some test descriptions were split over input lines, leading to ragged output (suppressed under harness testing).
As suggested by Dave M. in Perl#23278 (comment).
Currently, a CONST OP's SV will not have the `IsCOW` flag set if the PV buffer was truncated such that it is too small to be COWed. In which case, not short circuting `Perl_op_convert_list` causes the OP to undergo constant folding, resulting in a CONST OP with an SV that can participate in COW. This means that the commit which introduced the short-circuit for CONST OPs accidentally introduced a regression: Perl@a902d92 This commit adds an additional check to ensure that short circuiting does not happen when the CONST OP SV cannot be COWed. This is a short term workaround given the proximity to the next stable release. Perl#23290 seems like the more appropriate fix, but is a bigger change, so will be held until the next development cycle.
Add example of how it handles numbers that aren't decimal positional. I thought it would clarify things to expand and correct the flawed example pointed out in GH Perl#23003.
I noticed that nowhere in our documentation do we introduce the concept of sigils. This is something that distinguishes Perl from most other languages, so could easily be confusing to a newcomer.
It has not effect. "adopting flags from ldflags is supposed to happen in Configure, not in hints." - leont Configuring a build of perl with -Aappend:ldflags=" -L/var/empty" and checking the output of 'perl -V:ldflags -V:lddlflags' shows ldflags=' -L/var/empty'; lddlflags='-bundle -undefined dynamic_lookup -L/var/empty'; Found when analysing issue Perl#9437 Tested on OS X 10.4 aka Darwin 8.
So it can be appended, otherwise it just hardcodes lddlflags="-bundle -undefined dynamic_lookup" Make sure MACOSX_DEPLOYMENT_TARGET is added to $lddlflags.
Need to be explicit with OS' for macOS 11 and up here. Otherwise: Unexpected MACOSX_DEPLOYMENT_TARGET=11
Unless MACOSX_DEPLOYMENT_TARGET is passed into the build, just ride the defaults of the OS' toolchain. This code assumes OS X versioning (10.15.x ) and tries to drop the patch version from the product version so that you're targetting macOS 10.15, rather than 10.15.1. Unfortunately with macOS 11 and up, it ends up targetting the patch version and since we're no longer appending $ld to $lddlflags we end up with the core targetting the major version and the modules targetting the patch version. Resulting in warnings ld: warning: object file (/Users/runner/work/perl5/perl5/cpan/Compress-Raw-Bzip2/Bzip2.o) was built for newer 'macOS' version (14.7) than being linked (14.0)
…darwin-lddlflags-tweak
|
bleh, there goes a pull request. |
It has not effect.
"adopting flags from ldflags is supposed to happen in Configure, not in hints." - leont
Configuring a build of perl with -Aappend:ldflags=" -L/var/empty" and checking the output of 'perl -V:ldflags -V:lddlflags' shows
ldflags=' -L/var/empty';
lddlflags='-bundle -undefined dynamic_lookup -L/var/empty';
Found when analysing issue #9437
Tested on OS X 10.4 aka Darwin 8.