#60748 closed defect (invalid)
perl5 modules that need to be compiled fail on Tiger Intel with unrecognized "-fstack-protector-strong"
| Reported by: | kencu (Ken) | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Tiger | Cc: | |
| Port: | p5.28-encode p5.28-pathtools p5.28-scalar-list-utils p5.28-b-cow |
Description (last modified by kencu (Ken))
I manually forced encode, pathtools, scalar-list-utils, b-cow to gcc7 and then said “stuff this” and set the default compiler to gcc7 temporarily to build 60 more.
I didn’t bother opening many redundant tickets.
We could:
- blacklist gcc-4.2 on all those ports that fail
- figure out why -fstack-protector-strong is being used when it is unsupported.
Attachments (1)
Change History (12)
Changed 4 years ago by kencu (Ken)
| Attachment: | p5.28-scalar-list-utils-stack-protector-error-gcc42.log added |
|---|
comment:1 Changed 4 years ago by kencu (Ken)
| Description: | modified (diff) |
|---|
comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Is it possible that you built your perl5.28 using a newer gcc? That could explain why perl thought, at the time it was built, that -fstack-protector-strong was supported. Here's a similar report from another project where building perl on a system that supported -fstack-protector-strong caused the error you reported when that perl was installed on a different system that didn't support -fstack-protector-strong.
comment:4 follow-up: 7 Changed 4 years ago by kencu (Ken)
I did build it with gcc7 due to 60740
perl5.28 will build with gcc-4.2 but only if it can link against libssp_nonshared from a newer libgcc that happens to be installed, so that seemed too tenuous so I just built it with gcc7, that had an official call in to libgcc7 to supply the libssp_nonshared.
but it appears that has more repercussions, so maybe the better fix is to stop perl building against libssp_nonshared when building with gcc-4.2...
comment:5 Changed 4 years ago by kencu (Ken)
that patch you referenced looks like exactly what we might need, on these systems < 10.6 that default (at present) to a gcc version < 4.9. thanks for finding that.
If we patched perl with that, then it would not look for libssp_nonshared, the existing patch to disable linking in ${prefix}/lib could likely then stay, and (hopefully) all the perl modules would not have trouble building.
Let me try that out, and if it works like it should, I'll see if I can tuck that quietly into the perl build somewhere Mojca won't have trouble with.
comment:6 Changed 4 years ago by kencu (Ken)
now I just need to figure out a way to test if ${configure.compiler} matches some gcc version < 4.9... that should an interesting trick :>
comment:7 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:8 Changed 4 years ago by kencu (Ken)
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
Yes, reasonable.
comment:9 follow-up: 10 Changed 4 years ago by kencu (Ken)
This is invalid only in the sense that in this case perl had to be built with a non-default compiler to make it build, and this led to errors because that was not the system's default compiler.
It is to be noted that perl has to be built with the weakest, least capable compiler on the system that could ever be called in for a build, because it incorporates flags into itself to configure the builds of any modules it tries to build in the future, and if some less-capable compiler is called in to build the module, the module build will (often) fail.
comment:10 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to kencu:
This is invalid only in the sense that in this case perl had to be built with a non-default compiler to make it build, and this led to errors because that was not the system's default compiler.
And that's why it's invalid: you broke perl5.28 by building it with a compiler it wasn't supposed to be built with. It's not a bug in the port, it's not something we need to spend time trying to fix. We don't support users building random ports with random compilers. We need to fix #60740 so that you can build perl5.28 with compiler it specifies.
comment:11 Changed 4 years ago by kencu (Ken)
I believe we have forced ports to build with a newer compiler about -- oh -- 200,000 times so far this year :)
Sorry to waste your time. You can leave all this with me if you like. I am not sure why I bother to open tickets actually, as I'm doing all the fixing anyway.
But thanks for the clue about perl burning it's build flags into it's script. That was helpful
On my High Sierra machine,
-fstack-protector-strongappears in /opt/local/lib/perl5/5.28/darwin-thread-multi-2level/Config_heavy.pl. I assume that's what controls it getting into the build. I assume based on what you said that with the older gcc-4.2 it shouldn't be there. You could look through the configure log of perl5.28 to see if it says anything about detecting-fstack-protector-strong. The sentence "Perl is now compiled with "-fstack-protector-strong" if available" appears in the perl5.22.0 changelog.