Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
OS-1588 breaks the build. #9
The issue is that we're picking up the Config_heavy.pl from the platform. So this wasn't caught in the build where it should have been. (Thanks Keith W, for the thoughts on IRC last night regarding finding this nasty thing!)
I've proven this by adding a fixed Config_heavy.pl to my fake-subset, and gotten the build to go through, from what was previously a "broken" zone. (You only have to change the -fPIC to a -KPIC and it goes right through.)
Joyeurs(sp): You can reproduce by using a later platform on your build boxes. Anything past that commit will likely break, future builds.
How to fix this in a non-disgusting manner, "good question." But people should be aware there is a build corruption right now.
How this shows up: -fPIC is not a recognized flag by cw.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
There are two basic problems here. First, the reason this problem was not caught sooner is that the ON perl module build system does:
This would be ok if this perl were being used as a tool, but what it's actually doing is building software intended to be interpreted by $(PERL). That means this must change to use either the adjuncts or proto.strap. Since we do deliver perl and thus already have the knowledge necessary to build it, proto.strap seems more correct. So step 1 is, as ira suggested, to build a bootstrap perl and teach the ON module build system about it.
The second problem is that the ON perl build assumes that the perl from which it obtains its build-time configuration was itself built with and installed to provide configuration for building with Studio. This was historically the case but currently is not, and it is this change that directly induced the failure. That configuration is really never useful since Studio is neither used to build perl nor available on SmartOS systems. ON is the only consumer. Historically, the PerlGcc package was then intended for use by customers wishing to build perl modules who did not have Studio; however, practically speaking Studio is dead and no one should ever be building modules against the platform perl anyway.
The simplest way to correct this would seem to be to revert the gcc-specific portions of the OS-1588 change, modify illumos-extra to create a bootstrap perl, and force the ON modules to build using the bootstrap instead of whatever's on the running system. In order for this to work correctly, the bootstrap perl will need a separate configuration from the installed one -- for example, it needs to provide -I and -L options pointing at the proto area rather than the running system, but -R options pointing at the running system. There will likely be additional challenges in implementing this.
Given the hideous nature of the perl build system and the fact that this is still an incomplete fix (see OS-1828), it's apparent that perl really just needs to go away entirely. This can't happen until the last of the perl utilities in ON are eliminated. Many of the modules in ON could actually be removed, as they're not consumed by anything in ON (i.e., they aren't needed in the platform, and consumers can obtain them via CPAN or pkgsrc in zones). Unfortunately a few of them are still used by the hated intrd, so that wouldn't solve our problem.