Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jun 2003 11:20:38 +0200
From:      Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
To:        naddy@mips.inka.de (Christian Weisgerber)
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Ports that don't run on !i386
Message-ID:  <m3wuf98aah.fsf@merlin.emma.line.org>
In-Reply-To: <bdd11o$6mc$1@kemoauc.mips.inka.de> (Christian Weisgerber's message of "Wed, 25 Jun 2003 20:35:04 %2B0000 (UTC)")
References:  <bdd11o$6mc$1@kemoauc.mips.inka.de>

next in thread | previous in thread | raw e-mail | index | archive | help
naddy@mips.inka.de (Christian Weisgerber) writes:

> When I pick up submissions for updates to unmaintained ports I do
> a test build and install.  Sometimes I also do a minimal test run.
> And sometimes the port will not run on my -CURRENT/alpha, which I
> use for that work.  A good many of those cases are very likely due
> to the port not working on alpha (and probably neither on several
> other of our !i386 platforms).

Well, sometimes checking buildd.debian.org, albeit Linux, turns out to
be very useful to extract common failure cases -- at least for the
upstream maintainer. Debian buildd boxen (that cover the Debian
architectures) may reveal 64bit problems that appear on other systems.

I've collected some portability experiences with mail/bogofilter, which,
at some point in time, didn't work on Solaris when compiled with Sun
Workshop for sparcv9 (64bit) when gcc 64-bit was fine -- fixing these
Sun Workshop issues fixed different and non-obvious FreeBSD sparc64
issues at the same time.


As a general hint to upstream maintainers, the serious problems I have
encountered so far with ports to !i386 are for the most part:

- type width issues, i386 encourages and does not detect careless mixing
  of size_t, int, [u]int32_t and long, which is fatal on 64-bit
  archs. This is an issue because most ports are written in C which is
  pretty much ignorant about types.

- pointer alignment issues with custom "fast, pooled" (ahem) memory
  allocators that bite RISC (and m68k) machines with SIGBUS, and infer
  performance penalties...

Other less serious issues comprise tons of signedness warnings, Sun
Workshop is a lot pickier than even gcc 3.3, and I consider compiler
pickiness a good thing.

Needsless to say that lint or splint would catch a good deal of these
issues (as would compiling stuff in C++ mode, although there are some
valid C constructs that are invalid in C++) -- it's a matter of software
quality in general, not limited to FreeBSD, and it takes weeks of work
to clean up even for "splint -weak", such type checking needs to be done
during the development process already.

-- 
Matthias Andree



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m3wuf98aah.fsf>