Definitely more than a week, I’ve not had a chance to devote much time to this over the past few months due but have made sufficient progress to qualify another post.
The most import thing is apart from one PR, all previously submitted patches have now been committed to pkgsrc-current, pkg/49082 still remains.
With the introduction of GCC 4.9, the same changes needed to be applied to
lang/gcc49 as with previous versions, pkg/49178 took care of that, however this highlighted another problem. 32bit & 64bit hosts running Darwin both identify themselves as
powerpc in the
uname(1) output which means that GCC is always built with multilib support disabled, even when building on a 64bit host.
Some of the cross compilation tools for micro controllers were hardcoded to use
ksh to build with when in fact it was only required for NetBSD >= 5, this caused the build to break on Tiger (assuming because of the old version of bundled ksh), pkg/49311 fixed that for
cross/binutils but the changes were also applied to
devel/binutils by the maintainer.
cross/avr-libc was previously broken because it was using the system compiler & headers instead of
avr-gcc and the headers installed in pkgsrc during builds. pkg/49316 fixed this issue and upgraded the version to v1.81 of avr-libc.
It’s no longer a requirement to declare the
MACOSX_DEPLOYMENT_TARGET environment variable to build
lang/perl5. By default Perl declares this to be 10.3 which is no longer applicable on modern systems and when building with clang
mmacosx-version-min is specified, making it redundant. This had been removed in pkgsrc via a patch and it broke the build for GCC users as without this variable the target defaults to 10.1 and Perl needs specific attention for versions prior to Panther. pkg/49349 added this variable back in for Darwin 9 and prior which were GCC only releases. Bug #117433 in the Perl RT was the source of the patch proposed to resolve the issue.
lang/ocaml now builds on Tiger, the workaround for the lack of support for
-no_compact_unwind in the shipped linker was applicable to prior releases and not just specifically Leopard, pkg/49417 fixed that.
devel/py-py2app previously failed to build on PowerPC OS X due to an error in the PLIST, the use of the
MACHINE_ARCH variable would expand to
powerpc which raised a packing error. pkg/49418 fixed that.
devel/cmake still remain broken in the pkgsrc tree for Darwin PowerPC, I was able to generate a MesaLib package successfully by forcing static binaries which allowed the previously unattempted packages to be tried in a bulk build of the entire tree. Unfortunately I hadn’t caught a merge conflict from when pkg/49077 was committed and so devel/icu was not built, this caused a another large subset of packages to not be built.
Thanks to the pointer from Jonathan Perkin, after I’d resolved the merge conflict I removed the entry in
/mnt/bulklog/meta/error and ran
bulkbuild-restart to re-attempt building devel/icu & those which depended on it.
With these changes, there were over 10000 packages available on sevan.mit.edu but unfortunately that included lots of duplicate packages from previous bulk builds.
pkgtools/pkglint has the ability to scan packages against a pkgsrc tree & remove duplicate/stale packages. Running
lintpkgsrc -K /mnt/packages -pr took the number of packages down to 9200. There is an AWK based solution but I’ve not had a chance to try it.
I was able to get
devel/cmake to build successfully by removing the references to
Modules/Platform/Darwin.cmake and subsequently build packages such as
databases/mysql56-client but I’ve not added the changes to the tree yet. Will look to add this in a future bulk build, I want to get MesaLib linking correctly first before adding more kludges into the mix. The next thing I want to try is using a newer version of linker from
devel/binutils instead of the one bundled with Xcode.