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>