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

+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.)

Is it really appropriate to have this depend on the configuration of the build system, a la

​.if exists(/usr/lib32/libc.so)

? This does not appear to guarantee reproducible builds, does it?

(Adding Andreas Tobler as reviewer.)

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.

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.

And why not lang/gcc5, lang/gcc5-devel, and lang/gcc6-devel?

As you apply this, please start with the newest port and work your way down
to older ones (just in case, best practice).

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.

Then why is the port still in the tree? As long as it exists, it should be fixed to minimize surprises down the road. I wasted enough time testing builds between lang/gcc vs. lang/gcc48 when I first encountered these build issues because I did not realize they were pretty much the same port...

And why not lang/gcc5, lang/gcc5-devel, and lang/gcc6-devel?

Oh... just because I did not notice them! Patch updated.

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.

OK, that explains why I did not observe any differences in the packages being built on amd64. Because powerpc64 is the only platform in which this makes sense, the option should only exist in it; patch modified to do so.

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.

One question, having though a bit more about the logic and our usual usage. Wouldn't
it make sense to always define this option, default it to false and only default it to true
when usr/lib32/libc.so exists?

So something like

 :
OPTIONS_DEFINE=...MULTILIB...
MULTILIB_DESC=                Build support for 32-bit and 64-bit targets where applicable
MULTILIB_CONFIGURE_ENABLE=        multilib
:

.if exists(/usr/lib32/libc.so)
​OPTIONS_DEFAULT_powerpc64=        MULTILIB
.endif

In this case we do _not_ need the general ​CONFIGURE_ARGS+=--disable-multilib any more.
And if someone actively sets the MULTILIB option, there will be an error when we are not able
to build (which makes sense I'd say).

What do you think?

(Note the adjusted _DESC, Can we simply say "targets" instead of "target types",
regardless of the outcome of this question?)

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.

No, my question was: why is lang/gcc48 there when lang/gcc is pretty much a verbatim duplicate of it? If lang/gcc ought to work, so should lang/gcc48, especially because 4.8 is still the default gcc version.

One question, having though a bit more about the logic and our usual usage. Wouldn't
it make sense to always define this option, default it to false and only default it to true
when usr/lib32/libc.so exists?

So something like

 :
OPTIONS_DEFINE=...MULTILIB...
MULTILIB_DESC=                Build support for 32-bit and 64-bit targets where applicable
MULTILIB_CONFIGURE_ENABLE=        multilib
:

.if exists(/usr/lib32/libc.so)
​OPTIONS_DEFAULT_powerpc64=        MULTILIB
.endif

In this case we do _not_ need the general ​CONFIGURE_ARGS+=--disable-multilib any more.
And if someone actively sets the MULTILIB option, there will be an error when we are not able
to build (which makes sense I'd say).

What do you think?

This mostly works, but is suboptimal. Going this route allows the user to enable MULTILIB even when lib32 is not present, which would result in a build breakage. The MULTILIB option should only be exposed if the lib32 libraries are present.

(Note the adjusted _DESC, Can we simply say "targets" instead of "target types",
regardless of the outcome of this question?)

Done.

ping reviewers

Yes, you have already approved the revision before, but you should do so again because it has potentially changed quite a bit since you did that.

Thank you

I still am not fully convinced that the presence of OPTIONs should depend
on the host system, but since none of the portmgrs are concerned:

Approved-by: gerald (maintainer)

(Not sure how to add myself as Approver in this tool, but as maintainer of
these ports, that's all you should need. ;-)

Just swap MULTILIB_CONFIGURE_ENABLE and MULTILIB_DESC as you
commit, and start with gcc6-devel and gcc5-devel, giving those several days
before you go for the rest.

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.

gerald: To add yourself as reviewer, you should be able to click on the "Edit revision" button at the top right of the page and modify the list of reviewers.

Why did you allow to enable multilib for all archs on gcc4.9/gcc4.8? It is still a no-op for all archs beside powerpc64.

No, my question was: why is lang/gcc48 there when lang/gcc is pretty much a verbatim duplicate of it? If lang/gcc ought to work, so should lang/gcc48, especially because 4.8 is still the default gcc version.

lang/gcc is the general, default port that most people will want to use (and should).

Right now it is based on GCC 4.8, but there is a push to re-base on GCC 4.9, and
later GCC 5.