This isn't only about vax, so please read the explanations even if you don't care about that architecture.
I've been building a handful of 4.5 release packages for vax and I ran into many build failures. Now there's a lot of things the vax can't handle, but there are also a lot of *stupid* small mistakes that cause build failures which could easily be avoided. == C89 vs. C99 == vax and sparc still use gcc2. gcc2 is a C89 compiler and can't handle C99 constructs. In particular, C89 only allows variable declarations at the beginning of a block before any statements, whereas C99 and C++ allow declarations and statements to be mixed freely. A project may choose to use C99 and that's okay, but frequently misplaced declarations slip in by accident and the upstream will happily fix things to be C89-compatible if only somebody tells them. == Static Linking == >From time to time we have architectures that don't support dynamic linking. At the moment vax is the only one. Obviously things that require dlopen() won't work, but that's not the issue. Static linking has some constraints that are hidden with dynamic linking: * Inter-library dependencies Dynamic libraries can depend on other libraries and the linker will pull these in automatically. For example, libX11 depends on libXau and libXdmcp. With dynamic linking -lX11 is enough. But static libraries don't register these dependencies. You explicitly have to link with -lX11 -lXau -lXdmcp or you will see an error about unresolved symbols. (We used to explicitly not register inter-library dependencies so this would show up on all platforms, but we eventually gave up enforcing this.) * Link order With static linking, if object files or library A depend on library B, then library B must come after them on the command line. For example, -lcrypto -lssl will break. It has to be -lssl -lcrypto. Both of these problems can also appear in configure script tests, causing erroneous library detection failures. Maybe we can get regular package builds and error triaging going on the affected archs, so that people can be made aware of these problems and that the ports can be fixed. -- Christian "naddy" Weisgerber na...@mips.inka.de
