Following on from last week, I worked on components which caused large numbers of packages not to build.
textproc/icu failed to build due to localtime_r() not being used if either _ANSI_SOURCE or _POSIX_C_SOURCE is defined & using an opcode that the shipped version of assembler didn’t understand. Ticket #9367 provided fixes for both issues spanning over 2 years, pkg/49077 covers this but has not been committed.
databases/sqlite3 failed to link with ld: Undefined symbols: _OSAtomicCompareAndSwapPtrBarrier error, this is due to the lack of zone memory allocator, PR #49081 fixed this issue by defining -DSQLITE_WITHOUT_ZONEMALLOC for OS X releases prior to Leopard. This is PR was committed. A subsequent PR (pkg/49082) was raised to do the same for lang/tcl which also bundles its own copy of sqlite3 for its sqlite module, but has not been committed.
devel/pango was broken on OS X releases prior to Leopard as the package enabled the CoreText option by default but failed due to packing errors (CoreText is not available hence the .la file not existing when build has completed). pkg/49090 resolved the issue & was committed.
Packages for GCC 4.4 to 4.6 are now available, lang/gcc47 failed to build successfully with sh consumed all resources on a CPU before being terminated manually.
sh(22232) malloc: *** error for object 0x34e340: incorrect checksum for freed object - object was probably modified after being freed, break at szone_error to debug
sh(22232) malloc: *** set a breakpoint in szone_error to debug
sh(22232) malloc: *** Deallocation of a pointer not malloced: 0x34d7ab; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
sh(22232) malloc: *** Deallocation of a pointer not malloced: 0x34e340; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
checking sys/time.h usability... Makefile:16170: recipe for target 'configure-stage2-target-libgomp' failed
gmake[2]: *** [configure-stage2-target-libgomp] Error 137
This behaviour has previously been observed when attempting to build GCC on the PowerBook
The stability of sevan.mit.edu was improved by re-applying the 10.4.11 combo update.
Currently in the process of fixing devel/cmake, cmake now get through most of the build (it was previously failed at 3%) but fails at the linking stage due to path issues. It picks up the pkgsrc version of CURL as /usr/pkg/bin/curl but tries to link against libraries in /Developer/SDKs/MacOSX10.4u.sdk/usr/pkg/lib which doesn’t exist.
The TenFourFox blog mentioned the effort thanks to Cameron Kaiser of Floodgap.