Opened 3 years ago

Last modified 23 months ago

#64176 new defect

Some perl modules built with +universal only installed arm64 binaries

Reported by: jgrg (James Gilbert) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: arm64 x86_64 universal Cc: mojca (Mojca Miklavec)
Port: p5-math-random-isaac-xs p5-params-validate p5-www-form-urlencoded-xs

Description

Installing many perl modules with +universal on my M1 Pro Monterey machine, I have come across three which claimed to have installed universal versions, but the binary XS.bundle files installed only contain the arm64 architecture:

  p5.28-math-random-isaac-xs @1.4.0_1+universal (active)
  p5.28-params-validate @1.300.0_0+universal (active)
  p5.28-www-form-urlencoded-xs @0.260.0_0+universal (active)

Change History (6)

comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Port: p5-math-random-isaac-xs p5-params-validate p5-www-form-urlencoded-xs added

Normally you should file a separate ticket for each separate issue. Each port will need a separate fix for this issue.

I'm currently on Catalina on which universal building is not possible, but I can still see from a build log of p5.28-math-random-isaac-xs what the problem is:

CFLAGS='-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64'
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64'
--->  Building p5.28-math-random-isaac-xs
/usr/bin/clang -Isrc -I/opt/local/lib/perl5/5.28/darwin-thread-multi-2level/CORE -DUSE_INT -c -fno-common -DPERL_DARWIN -pipe -Os -fno-strict-aliasing -fstack-protector-strong -I/opt/local/include -DPERL_USE_SAFE_PUTENV -Wno-error=implicit-function-declaration -O3 -o src/rand.o src/rand.c
/usr/bin/clang -Isrc -I/opt/local/lib/perl5/5.28/darwin-thread-multi-2level/CORE -DVERSION="1.004" -DXS_VERSION="1.004" -DUSE_INT -c -fno-common -DPERL_DARWIN -pipe -Os -fno-strict-aliasing -fstack-protector-strong -I/opt/local/include -DPERL_USE_SAFE_PUTENV -Wno-error=implicit-function-declaration -O3 -o lib/Math/Random/ISAAC/XS.o lib/Math/Random/ISAAC/XS.c
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Math/Random/ISAAC/XS/XS.bs')
env LD_RUN_PATH=/opt/local/lib/perl5/5.28/darwin-thread-multi-2level/CORE /usr/bin/clang -bundle -undefined dynamic_lookup -L/opt/local/lib -Wl,-headerpad_max_install_names -fstack-protector-strong -o blib/arch/auto/Math/Random/ISAAC/XS/XS.bundle lib/Math/Random/ISAAC/XS.o src/rand.o

The CFLAGS and LDFLAGS MacPorts has requested are not being used. Presumably the same is true for the other two ports. However each port's build system will need to be individually investigated to determine why it is not honoring these flags and how to fix it. I'm not well versed in how perl modules build. I see a Build.PL file but I don't see any mention of CFLAGS or LDFLAGS in there so I don't know what needs to be changed. If you can figure it out, let us know or submit a pull request.

comment:2 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: mojca added

Or it could be a general problem. I see that all three of these ports depend on p5.28-module-build. Picking some other random port that also uses module build, p5.28-time-y2038, I see it does the same thing (doesn't use our -arch flags). Picking some random port that does not use module build, p5.28-dbi, I see that it does use our -arch flags like it should. So it could be a bug in module build.

Mojca, as our resident Perl expert, do you have any thoughts on this?

comment:3 in reply to:  2 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to ryandesign:

it could be a bug in module build.

Possibly https://github.com/Perl-Toolchain-Gang/Module-Build/issues/54

comment:4 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

It looks like when module build is used, the perl5 portgroup adds:

    configure.pre_args  Build.PL
    default configure.args {--installdirs=vendor --config cc=\"${configure.cc}\" --config ld=\"${configure.cc}\"}

but I don't see anything that tries to propagate the CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS.

comment:5 Changed 3 years ago by jgrg (James Gilbert)

Yes, it doesn't look like any attempt has been made to pass CFLAGS, CPPFLAGS, CXXFLAGS, and LDFLAGS to Module::Build. I think that Module::Build wasn't widely used until the i386 > x86_64 transition was complete, so it may never have been used for building universal binaries. The default MakeMaker config goes through and patches each Makefile with reinplace to add CFLAGS and LDFLAGS.

Binary Perl modules are usually built using the CFLAGS and LDFLAGS that were used to build perl, but it seems that MacPorts has some kind of cunning mechanism that keeps whatever flags are needed for universal builds out of the Perl config so that building a universal module doesn't happen by default?

comment:6 in reply to:  5 Changed 23 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to jgrg:

Binary Perl modules are usually built using the CFLAGS and LDFLAGS that were used to build perl, but it seems that MacPorts has some kind of cunning mechanism that keeps whatever flags are needed for universal builds out of the Perl config so that building a universal module doesn't happen by default?

Yes, Perl seems to be under the impression that whatever compiler and I guess flags were used to build Perl should be used to build perl modules as well. We do not consider that to be appropriate behavior in MacPorts so we prevent it from happening. From our point of view, every port build should happen with the compiler and flags that were requested for that build.

Note: See TracTickets for help on using tickets.