Compiling ports in a post-9.0-RELEASE world

Matthias Andree mandree at
Thu Mar 17 17:49:33 UTC 2011

Am 16.03.2011 12:02, schrieb Ade Lovett:
> On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote:
>> 16.03.2011, 13:33, "Ade Lovett"<ade at>:
>>> On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote:
>>>>   What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R?
>>> With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures.  i386/amd64 for primary use, arm/mips for embedded.  Anything else is just ridiculous.
>> What about Power Architecrure (formerly PowerPC)?
>> It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.)
> Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't).
> Let's take the embedded example at random (well, not so much, since we both brought it up).  Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff.  That's the low hanging fruit.  In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system.
> With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box.
> Enough is enough.

To make a very clear point: We wouldn't be having this discussion if 
authors would write proper and portable code in general.  Not make 
silent assumptions about data width.  Use proper POSIX headers rather 
than guess endianness or type width from arch-dependent preprocessor 
macros.  Forget about pre-SUSv3 systems, or at least pre-SUSV2.  Don't 
second guess from high-level system feature, but query the actual low 
level feature, or hardcode type widths if we're talking about binary 
data layout (file systems, file formats, or wire protocols, for instance).

I don't mean to offend anyone or this to be taken reproachful, but it's 
just an observation:  I've seen so much code make implicit assumptions 
such as sizeof(long) == 4, endianness being "little", OS being Linux, or 
if it's not i386 or alpha then foo and all that when in fact all the 
support such as inttypes.h or sys/endian.h for the few bytes that needed 
it had been in place when the code was newly written.

I'm not asking about the reasons, but as an example: don't look at 
__i386__ if you need to know type widths and endianness.

Getting this stuff shaken out and done right usually means not 
supporting one more platform per iteration but usually the whole lot. 
And it often also removes other system dependencies.

Yes the releases * arches * compilers diversity is worrisome with 
expectations of lots of work, but the way to handle it is getting the 
code right.  I expect that upstreams will be more attentive, too, as 
more core code might want to be ported to Android, for instance.  And 
usually portable code is also better code in the sense that it is more 
robust and has fewer branches (or the branches are encapsulated in the 
magic under /usr/include).

Pointing people to NetBSD and/or pkgsrc isn't helping anyone.  If some 
arcane Java port fails on an architecture that's typically used for 
low-power, battery-powered, embedded stuff, so be it.  But quite a lot 
of the console/infrastructure stuff can be fixed with little effort, and 
I'm not supporting artificial limitations.

Matthias Andree
ports committer

More information about the freebsd-ports mailing list