perl5.* files contain -arch flags

[ryandesign (Ryan Carsten Schmidt)]

I'm trying to add a port for exact-image; see #24614. I'm having trouble because my perl5.8 is built universal, and exact-image cannot build universal, but it's still trying to build some parts universal because it's getting the universal -arch flags from perl using the command

perl -MExtUtils::Embed -e ccopts

Ports should not install files containing their -arch flags for the reasons explained in PortfileRecipes.

[ghosthound]

First off I suspect that what you're trying to do won't work - perl docs are pretty clear that you have to build the code you're embedding perl into in the same way that you built perl. Maybe it would work if the way you're trying to build exact-image (say, for x86) is the same way that that perl was build for x86.

As well, I'm concerned that some other ports may break if we remove ExtUtils::Embed support - for example the postgresql84 port (w/ +perl) uses:

$PERL -MExtUtils::Embed -e ldopts

to determine how to link in the perl library.

Can you patch the exact-image configure script to work around the problem?

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

Could you refer me to the specific documentation you're talking about? It should not be a problem to build a perl module for x86_64 only if perl itself was built for x86_64 and i386. This works fine for a whole lot of other software; I don't see why perl should be different.

I'm not suggesting you remove ExtUtils::Embed; "perl -MExtUtils::Embed -e whatever" should continue to return what it does now, but minus the -arch flags which it should not return for the reasons explained in the wiki page I linked to above. It's not particularly efficient to expect every perl module to patch this when the correct place to patch it is at the source -- perl itself. The only file in perl5.8 that I found that contains -arch flags is Config_heavy.pl, so I'm just proposing we remove the -arch flags​ from that.

[ghosthound]

Replying to ryandesign@…:

Could you refer me to the specific documentation you're talking about? It should not be a problem to build a perl module for x86_64 only if perl itself was built for x86_64 and i386. This works fine for a whole lot of other software; I don't see why perl should be different.

I'm not suggesting you remove ExtUtils::Embed; "perl -MExtUtils::Embed -e whatever" should continue to return what it does now, but minus the -arch flags which it should not return for the reasons explained in the wiki page I linked to above. It's not particularly efficient to expect every perl module to patch this when the correct place to patch it is at the source -- perl itself. The only file in perl5.8 that I found that contains -arch flags is Config_heavy.pl, so I'm just proposing we remove the -arch flags​ from that.

For documentation, see 'perldoc perlembed', in particular the section under "Compiling your C program".

Have you tried building perl w/ the proposed change(s) and then building something to use the embedded features, for example 'ImageMagick +perl' to ensure it still works? This should be tested w/ perl5.10 and perl5.12 as well.

What other modules and/or ports would require this change?

[ryandesign (Ryan Carsten Schmidt)]

I don't know the answers to all your questions. I do know that ImageMagick +perl builds fine with this change. And I know the current situation without the patch is broken and a patch like the one I submitted is needed. I've had that patch in place on my system for most of the past 4 months and I don't think I've encountered any problems as a result. To verify that the situation without that patch is broken, you need only install perl5.8 with the +universal variant and then attempt to install silc-client, which does not have a universal variant. It will fail with the message

gcc-4.2: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags

You'll see "-arch x86_64 -arch i386" in the log, confirming that silc-client is trying to build universal, though we did not request it and though the portfile explicitly disables it. It is inheriting these arch flags from perl5.8's configure script. This is why the arch flags must be removed from the files perl5.8 installs. If individual p5 modules then have trouble building universal, we can address those issues in those portfiles, but I do not anticipate any such issues.

[ghosthound]

This is why the arch flags must be removed from the files perl5.8 installs. If individual p5 modules then have trouble building universal, we can address those issues in those portfiles, but I do not anticipate any such issues.

I'm concerned that perl modules/interfaces won't build, not that they won't build universal. Perhaps perl should be marked with "universal_variant no" instead, that seems like it will avoid the problem you're having.

If someone has some time to test the above patch and build a variety of perl XS type modules (postgresql could be a good one, p5-gtk2 could be good as well) to make sure things work, that would be a big help in resolving this issue.

[ryandesign (Ryan Carsten Schmidt)]

I already built hundreds of perl modules with my patch in place and used it for months and it seemed to be fine.

I believe the problem described in this ticket is the cause of #27212 and that my patch should be applied to fix it.

[ghosthound]

Replying to ryandesign@…:

I already built hundreds of perl modules with my patch in place and used it for months and it seemed to be fine.

I believe the problem described in this ticket is the cause of #27212 and that my patch should be applied to fix it.

Do these perl modules include embedded C code? Have you tried any of the suggested ones (as above) and demonstrated that they work okay with this patch?

[danielluke (Daniel J. Luke)]

As noted in #28820 - apple ships with a similar patch:

​http://www.opensource.apple.com/source/perl/perl-63/5.10/fix/Config_heavy.pl.ex

We should be doing this for all of our perl5 ports.

[ghosthound]

Replying to dluke@…:

As noted in #28820 - apple ships with a similar patch:

​http://www.opensource.apple.com/source/perl/perl-63/5.10/fix/Config_heavy.pl.ex

We should be doing this for all of our perl5 ports.

I've asked for some help testing for the concerns I've got about applying the attached patch, and gotten only one data point (that ImageMagick +perl appears to work fine). If anyone is able to apply the attached patch (or modified for later perl versions) and build ports that include XS code (postgresql, p5-gtk2 are two examples) and verify that they work correctly (not just build, but run properly too) that would help these changes get committed (or not if they turn out not to work).

[ryandesign (Ryan Carsten Schmidt)]

I already said 6 months ago that I built hundreds of perl modules with the patch in place and believe it works fine. I assume several of them were compiled, linking against C libraries. I don't necessarily use the perl modules myself, but I have to believe that the perl modules themselves use the other perl modules.

I believe #29524 is caused by this problem as well.

[mfeiri]

AFAICT #29524 essentially describes the same problem. Marked it as a duplicate.

[drkp (Dan Ports)]

#31402 is also the same problem (at least partly).

[jeremyhu (Jeremy Huddleston Sequoia)]

This causes obscure build failures. net-snmp has fallout (#32507), and rxvt-unicode can also fails to build due to this.

Let's please push this change. If any fallout occurs, we can deal with it in those cases, but this is *clearly* wrong, and Ryan's patch is *obviously* correct. Yes, there may be something that depends on these being set, but we should not avoid fixing one bug because it exposes another!

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[drkp (Dan Ports)]

Yes -- I've applied this patch (locally) to all of the perl5.x ports and have been using them for a while. I've built about 200 p5.12 modules, some universal and some not, with a universal perl5.12. I can't say I've carefully tested every one of them, but I do use the programs that depend on them and haven't observed any problems. I'd also expect problems with this to manifest as build errors, and I haven't seen any.

Not surprisingly, it does fix the build failures we'd expect it to (e.g. #31402, #29524).

Unless anyone knows of something that would be broken by this, or otherwise objects strongly, I will commit the fix.

[drkp (Dan Ports)]

Fixed in r87968.