Note that this is not a workaround: this is a proper fix for broken code.

I think this is fine. I just wonder if we should just zero out the parameters instead, or hardcode them to known values. I can't imagine a well-behaving compiler that wouldn't correctly build the test programs just with a call to ${CC} and no explicit flags.

bapt, this still requires your review as mentor. Thanks!

I've fixed sys/kqueue/kqueue_test for correctness reasons, but it needn't fixing from a parallelization point of view. The driver of those tests is a TAP test program, and Kyua cannot parallelize the execution of individual test cases within a TAP test program.

Also mark etc/rc.d/routing_test and sys/netinet/fibs_test as requested by asomers

Also mark sys/geom/class as exclusive

Looks good, but it's unfortunate that this is the case.

ngie is right in that basename and dirname are used for sanity-checking purposes. Why this is in the live code path and not in tests... doesn't make much sense, and I guess this could all be dropped.

Updated distinfo with final checksum of actual release.

I messed up the commits and this was only intended to be enabled on powerpc64. I think I committed an older version of the diff. I have undone the committed changes and will take a closer look at what happened.

I only committed a subset of the changes, so let's reopen this. The automatic closing caused by a commit wasn't desirable in this case.

Sorry for not submitting this promptly, but I was waiting on mentor approval...

Thank you everyone. I've done the last stylistic change requested by gerald and committed the changes to gcc5-devel and gcc6-devel. The rest will follow later in the week.

ping reviewers

Fix description according to suggestion.

In D3952#83510, @gerald wrote:

Re "why is lang/gcc48 still there?", there is a number of users interested in older versions,
which by definition do not make much sense for newer ports or newer uses, though.

In D3952#83410, @andreast wrote:

Ok with me.
I often used to build with --disable-multilib to save time. But I usually have a lib32/libc.so. So if this test works, fine.
powerpc64 is the only target in FreeBSD land which has multilib support in gcc. For all other targets the --disable-multilib is a nop.

In D3952#83418, @gerald wrote:

Okay, so it's okay to make this change for lang/gcc, lang/gcc49 and later.

Let's leave lang/gcc48 alone, there should be no reason to use this any more.

Patch gcc 5 and 6 as well and only offer MULTILIB on powerpc64.

I'd say depending on the presence of /usr/lib32 is fine. The builds will be reproducible for the host building the packages, and the standard binary packages should be built on a host without src.conf tweaks. Once you've modified MK_* settings in src.conf, you are in la la land.

Suggestion applied. Given that you said "approved with this change made", which I have done, I'm going to submit now.

Committed as r399873. Thank you!

Make sure to disable multilib when MULTILIB is not defined.

Use MULTILIB_CONFIGURE_ENABLE.

+bdrewery. Let's add my primary mentor... my memory served me wrong and I got things backwards. (Now also waiting for a reply from Gerald via email; pointed him at here.)

Actually... +bdrewery. Had to look at my invitation email and now noticed that my primary mentor is Bryan, not Baptiste! Oops.

FYI: "make tinderbox" was successful and a bunch of test builds on amd64 and powerpc64 where I enabled/disabled lib32 and ran an update have worked as intended.

I'm going to poke gerald@ by email to take a look and possibly to register for a Phabricator account.

Add missing etc/Makefile to the diff.

Nest MK_DEBUG_FILES inside MK_LIB32 for consistency.

Thanks. Now... ping bapt / mentor!

Please take a look now. The intermediate revisions were kinda broken, but my tests as described in the test plan have now passed with the last patch snapshot.

And now fix a typo to allow deletion of the stale BSD.lib32.dist file.

Also patch etc/Makefile.

Add missing calls to mtree for LIB32TMP.

So, kwm, do you want this changed to a patch or is it good to go? See my previous comment for the rationale.

With much delay, this is now committed as r399507. Thanks!

This is your package, so it's up to you.

Oops... messed up the previous "arc diff" upload and pushed changes for
an unrelated package to this revision. Repushing for review.

Fix build on 64-bit big-endian machines.