Tag Archives: Mac OS X

Unable to mount or open disk images generated with Nero (.nrg file)

It appears that VirtualBox & OS X are unable to open .nrg files, despite them essentially being a ISO 9660 format file.

VirtualBox reports:
Result Code:
VBOX_E_IPRT_ERROR (0x80BB0005)
Component:
MediumWrap
Interface:
IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}
Callee:
IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}
Callee RC:
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

Finder reports:
image not recognised

This turns out to be due to a footer added by Nero which may make the file size something which in not a the sum of a multiple of 2K.

Editing the file in a hex editor and removing the footer (of 72 bytes) should result in the file being usable

28633000 45 54 4e 32 00 00 00 20 00 00 00 00 00 00 00 00 |ETN2... ........|
28633010 00 00 00 00 28 63 30 00 00 00 00 00 00 00 00 00 |....(c0.........|
28633020 00 00 00 00 00 00 00 00 4d 54 59 50 00 00 00 04 |........MTYP....|
28633030 00 00 00 01 45 4e 44 21 00 00 00 00 4e 45 52 35 |....END!....NER5|
28633040 00 00 00 00 28 63 30 00 |....(c0.|
28633048

A week of pkgsrc #9

The past few weeks have been pretty hectic, as the time for BSDcan gets shorter and shorter, I’m thinking about my talk and testing more and more in pkgsrc. Rodent@ added support for Bitrig to pkgsrc-current last month, his patches highlighted an issue with the autoconf scripts (which should be shared across core components) not being pulled in automatically. Joerg Sonnenberger resolved this issue and I regenerated the patch set again. With the system bootstrapped the next thing which was broken was Perl, applying the changes needed for OpenBSD resolved any remaining issues and the bulk build environment was ready. After three days, the first bulkbuild attempt on Bitrig was complete and a report was published. There is now a bulkbuild in progress with devel/gettext-tools and archivers/unzip fixed, that should free over 8400 packages to be attempted to be built.
For Solaris, my first bulkbuild on Solaris 10 completed after 22 days. Mid-April I also started off bulkbuilds on Solaris 11 (x86 and SPARC) using the SunStudio compilers (It’s not possible to use GCC at the moment due to removed functionality that was previously deprecated). The Solaris 11 SPARC bulkbuild is still in progress and the x86 bulkbuild is running. Unfortunately the build cluster had some connectivity issues and needed rebooting during the bulkbuild but not until lots of packages had failed to fetch distfiles, hence the figures look a lot worse than they could be. Solaris 10 SPARC report, Solaris 11 x86 report.

Through bulk building on multiple operating systems another issue that’s surfaced is problematic packages that hold the build up. On Bitrig mail/fml4 is an issue, on OpenBSD www/wml, FTP mirror issues for ruby extension on Solaris, Xorg FTP mirror issues on OmniOS. Things need regular kicking, a brief glance into pkgsrc/mk didn’t reveal any knobs which would allow the preference of HTTP for fetching distfiles. On Bitrig & OpenBSD I’ve excluded these packages from being attempted via NOT_FOR_PLATFORM statement in their Makefile until I have a look into the issue.

sevan.mit.edu completed another bulkbuild, pkgsrc-current now ships with MesaLib 10.5.3 as graphics/MesaLib, version 7 has now been re-imported as graphics/MesaLib7 by tnn@, the new MesaLib needed a patch for FreeBSD, similar to NetBSD to build successfully, due to ERESTART not being defined. At present, it’s still broken on Tiger as I’ve not looked into yet.

I revisited AIX again to test out pkgsrc once again, this has turned into a massive yak shaving session. I’ve yet to run a bulkbuild successfully as the scan stage ends with a coredump.
I originally started off with using the stock system shell, bootstrap completed successfully but scan stage of a bulkbuild would just stop without anything being logged. Manually changing the shell used to shells/pdksh in pkg/etc/mk.conf and pbulk/etc/mk.conf resulted in the following error message:
bmake: don't know how to make pbulk-index. Stop
pbulk-scan: realloc failed:

This turned to be a lack of RAM, my shell account was to a AIX 7.1 LPAR running on a Power8 host with 2 CPUs and 2GB of RAM committed, unfortunately the OS image IBM provided came with Tivoli support enabled and a bug in the resource management controller which meant RMC was consuming way more resource than it needed to. I was running with less than 128MB of RAM.
Stopping Tivoli & RMC freed up about 500MB of RAM, attempting to bulkbuild again, caused the process to fail once again at the same stage. With a heads up from David Brownlee & Joerg Sonnenberger, I bumped the memory and data area resource limits to 256MB.
This allowed the scan to finish with a segfault.
/usr/pkgsrc/pbulk/libexec/pbulk/scan[54]: 11272416 Segmentation fault(coredump).
pscan.stderr logged multiple instances of
bmake: don't know how to make pbulk-index. Stop.
The segfault generated a coredump but it turned out that dbx, the debugger in AIX was not installed. IBMPDP on twitter helped by pointing to the path where some components are available for installation, unfortunately, while the dbx package was available there, some of its dependencies were not. Waiting on IBMPDP to get back to me, I fetched a new pkgsrc-current snapshot (I couldn’t update via CVS because it wouldn’t build) and re-setup my pbulk environment via mk/pbulk/pbulk.sh.
I should mention that initially when I setup, I’d explicitly set CC=/usr/bin/gcc last time, then while trying to get various things to build subsequently, I’d symlink /usr/bin/cc to /usr/bin/gcc. When I came to set thing up with the new snapshot, I did not pass CC=/usr/bin/gcc this time round and found that I was unable to link Perl, not sure if this was the Perl build files assuming if on AIX & /usr/bin/cc exists, it’s XLC or if ld(1) takes on different behaviour but I had to remove this symlink.
Once everything was setup, the bulkbuild failed agin at the same place, except this time I had a different message logged.
/bin/sh: There is no process to read data written to a pipe..
I edited the bootstrap/bootstrap script & devel/bmake/Makefile to set shells/pdksh as a dependency & rerun bulkbuild.
The scan stage again completed with a coredump with this time pscan.stderr just contained Memory fault (core dumped).
I’ve committed these changes so pkgsrc-current now defaults to using shells/pdksh as its shell but have not been able to try anything else as this weekend the system is unaccessible due to maintenance.

At present, I’m attempting to bulkbuild pkgsrc-current on 8 Operating systems
OpenBSD (5.6-RELEASE & -current), FreeBSD, Bitrig (current), Mac OS X (Tiger), Solaris (10 & 11), OmniOS on 4 architectures (i386, AMD64, SPARC, PowerPC).
If I could get AIX going that would bump the OS & arch could up by 1. Maybe by the next post perhaps. ūüôā

Thanks to Patrick Wildt for access to host running Bitrig and Rodent@ for adding support to pkgsrc.

Virtualising retail Mac OS X images on OS X with virtualbox

For testing changes related to OS X in pkgsrc I revisited trying to get virtual machines of the various releases of OS X running to improve test coverage. At present I’m confined to testing on Tiger and Mavericks though I also have machines running Leopard and Lion but they need setting up.
By default, it’s not possible to boot an instance of Mac OS X from a genuine install image, on a Mac host, running OS X using virtualbox.
Searching around reveals using modified images intended for building Hackintosh as the solution most people use. Virtualbox supports OS X guests but when following the usual steps in the wizard to create a new VM & pointing it to your unmodified OS image, nothing much happens.
Depending on the version of OS X you’re trying to boot you’ll either end up with a XNU hang/panic or just dropped straight to an EFI prompt.
Again, depending on the version of OS X being attempted the issue differs. I’ve managed to install 10.7 to 10.10 successfully on virtualbox so far. 10.5 & 10.6 remain to be done.

10.7 – Lion

With the release of 10.7, Apple changed the way OS was packaged, the digital distribution came with a disk image named InstallESD.dmg nested inside an application named Install Mac OS X Lion.app. It’s possible to use this disk image with virtualbox as-is without change however the system will not boot from the image because it fails a test by the boot loader to ensure the image is being booted on a genuine Mac. In my case it is, but unfortunately the cpuid virtualbox presents to the operating system is not one that the OS recognise & so it fails.
The solution to this is to tell virtualbox to mask the cpuid of the guest, unfortunately depending on the version of hardware? or virtualbox that you’re using you may have to experiment with which ID works. I first tried the ID 00000001 000306a9 00020800 80000201 178bfbff listed in the post by BitTorrent engineering but it did not work on a Mid-2012 MacBookAir5,1 with VirtualBox 4.3.22 r98236.
Searching around I found the ID 1 000206a7 02100800 1fbae3bf bfebfbff to try in a comment on another guide which did work.

To create a working VM of Lion in virtual
1) Create a VM in virtualbox named something, type Mac OS X, version Mac OS X 10.7 Lion (64 bit).
2) Before booting the VM, switch to Terminal and change the cpuid of the guest by running
VBoxManage modifyvm something --cpuidset 1 000206a7 02100800 1fbae3bf bfebfbff
3) Right click on Install Mac OS X Lion.app, select “Show Package Contents” and navigate to Contents/SharedSupport. Copy InstallESD.dmg to a locate on your disk which is navigatable.
4) Start the VM & when asked for an install disk, point to the InstallESD.dmg which you copied out in the previous step. The system should boot without any need for further modification (most guides recommend other changes such as switching to a PIIX chipset).

10.8 – Mountain Lion and newer

With Montain Lion, InstallESD.dmg was changed once again, this time to contain multiple partitions (EFI, Boot/Rescue, Install), unfortunately it’s not possible to boot these images successfully as the notion of multiple partitions is not applicable to media such as optical so what happens is that the system is able to boot from the disk image & load the kernel but unable to continue to load the install environment.
What needs to happen is a new “flattened” image needs to be generated which is on a single partition & contains everything from the boot partition.
There is no need to modify any settings for the VM such as cpuid as previous or chipset as recommended by other guides like Engadgets

To flatten the image a tool called iESD is used.
iESD can either be installed via gem(1) or if you’re a pkgsrc user, I’ve created a WiP package.

The instruction in the Engadget guide pretty much covers everything needed. Just make sure that the disk images are fully detached before issuing the hdiutil commands, quickest way being to open Disk Utility.app, selecting mounted disk images & pressing eject or checkout the output of hdiutil info & using hdiutil detach $devicename to detach all device names associated with the disk images.

A week of pkgsrc #7

Time again to write up what’s been happening on the pkgsrc front since last time, this time the focus hasn’t been so much around pkgsrc on Darwin/PowerPC but more about pkgsrc in general & not necessarily code related.
At the end of the last post I mentioned a gentleman who’d been working on pkgsrc/Haiku and posting videos of his progress, I managed to make contact with him (James) & discussed his work that he’d been doing on pkgsrc. He sent me copy of the repo he’d be working off so I could assist with the aim of getting everything upstreamed as in the current state everything would need to be reintegrated per quarterly release rather than only having to pay attention if a new issue has arisen.
After getting the correct version of Haiku installed in virtualbox, I discovered a nasty bug in the Haiku network kit, it was unable to detect when the end of the file had been reached & would continue (restart?), this was revealed when I tried to download the pkgsrc tar ball from via WebPositive, ftp from the terminal was not affected however. pkgsrc bootstrapped unprivileged without issue. Hint: use the nightly snapshots until there is a newer release than Alpha 1 available.
The integration of pkgsrc into the user-land on Haiku is not currently possible due to the way the user-land is constructed, from what I understood, each Haiku package contains a piece of the filesystem, all the packages are union mounted to construct the user-land dynamically when the system comes up. That aside, with my system bootstrapped, I attempted to build Perl and ran into another bug, it seems that the library path for libperl is not populated on haiku hence perl is able to “build” but unable to run, the workaround for this in the tree I was given was to symlink libperl into ~/pkg/lib & move on. I tried various things but was unsuccessful, I believe the problem is pkgsrc specific as the version of Perl available in haikuports do not need any special treatment and the rpath is passed in correctly.
The problem was trying to isolate the required change to fix the problem, whereas in pkgsrc a policy file is passed to the build to set how Perl should be built, haikuports clobbers the source & patches in a replacement, I stopped at that point.

Haiku nightly running in virtualbox

At around about this time I received the good news about the NetBSD Foundation membership and commit bit so my focus moved to reading the various developer documentation & getting familiar with processes.

sevan.mit.edu finished a bulkbulid attempt of the entire tree which took the longest time so far to complete, through all the build attempts I uncovered a new bug, the range to use for numerical IDs of UID/GID, is not sufficient to cover all the packages in the tree that need to create an account. On further discussion with asau@, it was suggested the IDs are allocated randomly and should be fixed for consistency across builds. I started doing bulkbuilds of the entire tree on FreeBSD 10.1-RELEASE and stumbled across a very nasty bug. There is a version of tcsh package in the pkgsrc tree called shells/standalone-tcsh, this is tcsh built as a static binary & set to install to /bin (the only package in the pkgsrc tree which violates the rules and places files outside of $PREFIX by default?), this ended up overwriting the system bundled version of tcsh in FreeBSD & then deleting /bin/tcsh when the package is removed, this was fixed promptly by dholland@. It was also discovered that Python’s configure script had not been changed when FreeBSD switched to elf binaries and so still trimmed the name of libraries to account for the old linker which could not handle a minor version in a libraries filename (libpython.so.1, not libpython.so.1.0). All versions of Python had been patched in the pkgsrc tree to remove this change so that it used a consistent naming convention across all platforms. After discussing this with bapt@ (FreeBSD) at FOSDEM, it turned out to be bug and should be fixed in future Python versions once the fixes are upstreamed.

Koobs@ (FreeBSD) dug out the commit which introduced the change & the bug report.

The opportunity to join the pkg-security team came up & for the past few weeks I’ve been getting familiar with the processes of dealing with security advisories & listing them so that users who fetch the pkg-vulnerabilities database are notified if they have any vulnerable packages installed. The general advisory process is a little infuriating, based on my recent experience I’d say at the top of my list are the Oracle security advisories as they do not divulge any details other than “unknown” in version(s) X, PHP for the frequency, OpenSSL for the impact. On the one hand I was quite impressed that CVE IDs were becoming so familiar that I could spot, on the fly, an advisory that had been accounted for, but on the other hand quite upset that I was using brain capacity on this. The availability of information is quite frustrating too, issues which are assigned an ID but cannot by checked on Mitre’s site take extra effort to find the necessary information to include (Mitre are responsible for allocating the CVEs!), I should note that this is from public advisories, say from a distribution. Example, CVE-2015-0240 was announced today, the Redhat security team published a blog post covering the issue, the Mitre site at present says:
“** RESERVED ** This candidate has been reserved by an organisation or individual that will use it when announcing a new security problem. When the candidate has been publicised, the details for this candidate will be provided.”
The wording & the lack of information can also be frustrating because it’s not clear what is affected. Looking at it positively, the requirement for clarification on these discrepancies means I get lots of opportunities to approach new people in different communities to ask questions.

I created a new wiki article on the NetBSD wiki to start documenting the bootstrap process of pkgsrc on Solarish, Illumos based distributions. At present the article covers what’s required to bootstrap successfully on OmniOS, Tribblix, OpenIndiana and OpenSXCE.

One thing that’s clearly evident is my workflow needs attention, at the moment things are very clumsy, involving lots of switching around but hopefully that will be addressed in the coming month. The first thing I’ve done is setup templates for emails with the correct preferences specified so that I just need to fill the necessary information & hit send, the necessary settings are automatically applied. Still thinking about how to deal with the scenario where the system that work is being carried out on is different to the system where the patch is going to be committed from, this also happens to be a different system which a developer is using. How to deal with that in as few steps from reading, say a bug report, to generating a patch, testing it & committing a fix.

For testing patches on Mac OS X, I revisited running OS X as guest on a Mac running OS X with virtualbox. Attempts in the past had not been successful & it seemed from search results that the only approach taken was to use modified OS images for hackintosh which I did not want to take. I have a genuine machine & genuine license, I shouldn’t have to resort to 3rd party images to run this. After whinging on twitter & referencing some older links I was able to successfully virtualise Mac OS X 10.7 to 10.10 in virtualbox. Will follow up with the details on that in a separate post.

OS X Lion as a virtualbox guest

A week of pkgsrc #6

Since the last post¬†I’ve made some further progress with pkgsrc on Darwin/PowerPC again, the biggest achievement was fixing lang/ruby19-base, lang/ruby200-base and lang/ruby21-base which accounted for the breakage of some 1500 packages (variation of 500 or so modules for each version of Ruby). This was caused by the failure to build the DBM module, which on OS X required the inclusion of dbm.h as well as ndbm.h otherwise all tests fail and the module is not built. The frustrating thing is that there appears to be no documentation for the build process of Ruby, luckily, by Ruby 2.0 there was a comment added to ext/db/extconf.rb to shed some light on the issue:
# Berkeley DB's ndbm.h (since 1.85 at least) defines DBM_SUFFIX.
# Note that _DB_H_ is not defined on Mac OS X because
# it uses Berkeley DB 1 but ndbm.h doesn't include db.h.

pkg/49508 was committed prior to the 2014Q4 pkgsrc release but
pkg/49511 and pkg/49512 did not.

cross/h8300-hms-gcc, databases/java-tokyocabinet devel/py-argh lang/smalltalk net/ser include some additional files which weren’t accounted for previously pkg/49473 & pkg/49474 pkg/49476 pkg/49478 pkg/49496 pkg/49498 fixed that.

devel/commit-patch used the -a flag for cp(1) which isn’t available on older operating systems, pkg/49475 switched to the use of -pPR instead (which -a is an alias of).

graphics/ivtools failed to build successfully due to a packing issue due to the explicit specification of operating system in the name of one of the generated files. pkg/49497 switched the use of the LOWER_OPSYS & added missing item which addressed the issue.

security/CSP failed at the installation stage due to the target directory not existing, pkg/49499 fixed that.

mail/nullmailer referenced uid_t & guid_t but did not include sys/types.h, pkg/49523 fixed that.

net/dnsmasq referenced SIOCGIFAFLAG_IN6, IN6_IFF_TENTATIVE, IN6_IFF_DEPRECATED & SIOCGIFALIFETIME_IN6 but did not include netinet6/in6_var.h when building on OS X which broke the build. pkg/49524 fixed that.

lang/lua52 failed to build on Tiger due to sys/types.h, pkg/49526 fixed that.

lang/php55 bundles its own version of sqlite and requires the necessary flags to disable features not available pkg/49527 fixed that but the correct fix is to not build an entire new version solely for PHP’s use. I began to look but had flashbacks of dealing with the same issue in TCL.

For graphics/MesaLib I looked to build it using a newer version of binutils but it appears that support for Darwin/OS X/iOS and Mach-o is rudimentary and hence missing support in most of the tools. Support began being added upstream to binutils back in 2011 but is still not complete.

For devel/cmake supports the ability to specify the location of library & header files, this can be done by creating a file which includes the necessary declaration that is passed to the configuration process using the --init flag. Indeed when the configuration process displayed the correct versions of OpenSSL, CURL, Zlib, BZip among others from pkgsrc rather than the older system bundled versions, unfortunately the build still failed when it came to the linking stage as the paths to the libraries was prefixed with /Developer/SDKs/MacOSX10.4u.sdk, as a kludge just to progress with the builds, I symlinked /usr/pkg to /Developer/SDKs/MacOSX10.4u.sdk/usr, the build then succeeded without issue. Next task is to work out how to drop the /Developer/SDKs/MacOSX10.4u.sdk prefix correctly.

There are currently 11132 packages available on sevan.mit.edu for Mac OS X/PowerPC with a new bulkbuild of the entire tree in progress. There are also Intel builds of the entire tree being attempted by Save OS X (64-bit packages) and Jonathan Perkin (32-bit packages) which should further improve support for OS X in pkgsrc.

Whilst browsing I discovered a series of videos on youtube by DisneyDumbazz, he has also been covering his work on improving support for Haiku in pkgsrc at length.
He was also struggling with issue in Ruby, QT4 & Mesa it seems.

A week of pkgsrc #5

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.

The pkgsrc guide pdf now has the correct date since pkg/49216, previously it reported 18/09/2007.

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 cross/freemint-binutils and 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.

graphics/MesaLib and 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 /Developer/SDKs in 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.

Restrictions on Apple hardware

I was recently looking for a link I thought I’d bookmarked on how to install recent versions of Mac OS X on EoL Apple hardware, specifically the Mac Pro. I was unsuccessful in finding the link I was looking for but I did find¬†that ¬†you can re-flash a MacPro1,1 with a MacPro2,1 EFI firmware, main benefit being microcode updates. Turns out the hardware in the first & second generation Mac Pro is identical bar the model of CPU available. There’s also modified images to bring the¬†MacPro4,1 to 5,1¬†which seems to provide much more benefit than the previously mentioned modification.

This got me thinking about some of the issues I’d¬†experienced¬†with¬†older apple hardware and the work arounds, it has been a while since I’ve posted something here so I wrote this post.

On the old world SCSI Macs (pre biege G3?) the drive vendor on the disk firmware with be identified as Apple which the Drive Setup utility (predecessor of Disk Utility) would look for, if it was not found, you would not be able to format your drive as HFS and hence be unable to install Mac OS. Work around was either finding another platform to format the disk or modify a copy of Drive Setup utility with ResEdit & add the drive to the necessary table.

The first of blue & white PowerMac G3 systems logic board shipped with a buggy CMD IDE controller which would corrupt data when doing DMA transfer, Apple shipped the disks in these systems with the firmware tied to PIO mode which was lots of fun when you came to replace the disk with a newer/bigger/faster one. To complete the replacement successfully, the new disk with need to be connected to a PC first & using the firmware utility provided by the vendor, make the same change of restricting the disks operation mode to PIO, otherwise it would not be possible to rely on the disk as data would be corrupted as you began writing to it, there was a recall for the motherboard If you were aware of the issue at the time.

The Mid/Late 2007 MacBook Pro (per advisory?) has the SATA port on the ICH8-M south bridge locked to SATA I even though it is capable of SATA II.

Most systems with user replaceable RAM are capable of taking more than official specification documents list. MacTracker Рan application which lists specs & information about Apple hardware provides advertised & actual maximum memory capabilities of system. Not so much a software based restriction but a documentation one.

A week of pkgsrc #4

AnyConnect login banner

Shortly¬†after the last blog post I had access to a couple of AIX LPAR. This would be my first time on a IBM PowerPC system and AIX, I’d applied for two AIX 7.1 instances, one defined as “AIX 7.1 Porting Image” and the other as plain “AIX 7.1”. The difference at a glance seemed to be the porting image had more gnu / common open source tools e.g GNU/Tar though both images had a version of GCC installed.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/powerpc-ibm-aix7.1.0.0/4.6.0/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ./configure --disable-multilib --with-cpu=powerpc --enable-debug=no --with-debug=no --without-gnu-ld --with-ld=/usr/bin/ld --with-pic --enable-threads=aix --with-mpfr=/opt/freeware/lib --with-gmp=/opt/freeware/lib --with-system-zlib=/opt/freeware/lib --with-mpc=/opt/freeware/lib --with-mpicc=mpcc_r --with-libiconv-prefix=/usr --disable-nls --prefix=/software/gnu_c/bin --enable-languages=c,c++
Thread model: aix
gcc version 4.6.0 (GCC)

The stock version came with GCC 4.2 built on AIX 6.1 whereas the porting image came with GCC 4.6.
Alongside the open source tools each instance also had proprietary tools installed including IBM’s compiler XLC, cc without any options invokes a man page which describes the different commands that represent a language at a level.

c99 – Invokes the compiler for C source files, with a default language level of STDC99 and specifies compiler option -qansialias (to allow type-based aliasing). Use this invocation for strict conformance to the ISO/IEC 9899:1999 standard..

The pkgsrc bootstrap process didn’t work too well by trying to allow it to workout things out for itself via cc so opted to use GCC specifically.

export CC=gcc

pkgsrc happily bootstrapped without privilege and I proceeded to install misc/tmux and shells/pdksh on AIX.

pkgsrc pkg_info on AIX

security/openssl comes with 4 different configuration settings for AIX, a pair of settings for the XLC & GCC compilers with a 32bit or 64bit target. It turned out that in pkgsrc it just defaulted to aix-cc (XLC with a 32bit target), pkg/49131 is now committed so the correct configuration is used, XLC successfully builds OpenSSL with a 32bit or 64bit ABI but GCC is only able to manage a 32bit target.

To switch compiler to xlc, declare it as the value to PKGSRC_COMPILER in your mk.conf.

Over the week I attempted to compile components of GCC 4.8 without much success, starting off with lang/gcc48-cc++ & falling back to lang/gcc48-libs.
The build process was very unstable, again as with the Tiger/PowerPC, the build would spin off & hang, pegging the CPU until killed. Attempting to restrict the processor time via ulimit didn’t have much effect.

Alongside trying to get GCC built on AIX, I kicked off building meta-pkgs/bulk-medium on sevan.mit.edu, the previously reported unfixed components prevented some of the packages from building again (ruby, MesaLib, cmake).

I began looking into fixing devel/cmake so that it would link against the correct version of curl libraries & use the matching header files, Modules/FindCURL.cmake in the cmake source references 4 variables which provide some control but I was unsuccessful in being able to pass these to the pkgsrc make process. While trying to resolve this issue I also discovered that on more recent version of Mac OS, the dependencies from pkgsrc ignored, opting for the use of the Apple supplied versions even though the pkgsrc version would be installed.

-- Found ZLIB: /usr/lib/libz.dylib (found version "1.2.5")
-- Found CURL: /usr/lib/libcurl.dylib (found version "7.30.0")
-- Found BZip2: /usr/lib/libbz2.dylib (found version "1.0.6")
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.dylib
-- Looking for BZ2_bzCompressInit in /usr/lib/libbz2.dylib - found
-- Found LibArchive: /usr/lib/libarchive.dylib (found version "2.8.4")
-- Found EXPAT: /usr/lib/libexpat.dylib (found version "2.0.1")
-- Looking for wsyncup in /usr/lib/libcurses.dylib
-- Looking for wsyncup in /usr/lib/libcurses.dylib - found
-- Looking for cbreak in /usr/lib/libncurses.dylib
-- Looking for cbreak in /usr/lib/libncurses.dylib - found

mail/mailman had a missing README in PLIST which was handled differently between Tiger & newer releases. pkg/49143 was committed to fix that.

A week of pkgsrc #3

Didn’t uncover anything new in pkgsrc last week as my attention was more on coreboot, I had previously been building different parts of the tree on a couple of Mac’s which where disconnected from each other & copying packages to sevan.mit.edu manually for serving, as a first off this was a good idea but bad as an ongoing thing. What ends up happening is stale packages become left behind as they are unaccounted for, luckily there aren’t too many duplicates currently but it’s something which needs to be addressed in the set of packages currently available.

There is now a page on the NetBSD wiki to keep note of issues & ideas.

To test the status of AIX support in pkgsrc I joined the IBM Power Developer Platform¬†which provides access to Power7/7+/8 systems running AIX 6.1 & 7.1 to build software on. This’ll be my first time on a Power system & AIX, looking forward to seeing what the OS is like.

System reservation on IBM PDP

With the addition of a G5 iMac to the effort kindly donated again by Thomas Brand, I started testing builds of lang/gcc48 on sevang5.mit.edu. Next step will be to get the two systems at MIT working together to build packages once I’ve been able to get GCC 4.8 to build successfully.

A week of pkgsrc #2

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.

A week of pkgsrc #1

This is summary of the things I worked on along with the help of others over the last week on pkgsrc.
With the donation of sevan.mit.edu along with a G4 Mac Mini at pksrcCon 2014 I setup bulk package builds as per chapter 7 of the pkgsrc guide to generate packages for OS X.
The bootstrap process is now able to differentiate between gcc & clang, as clang tries to be GCC compatible it tries to pass itself as GCC in tests, this would cause an issue where the bootstrap would use /usr/bin/clang for some parts of the build & /usr/bin/gcc for others, on top of that, the bootstrap process was hardcoded to use gcc on Darwin. The bootstrap process now defaults to using cc & correctly detects if that is clang or gcc.

By default git attempts to use the Apple CommonCrypto framework which meant it would only build successfully on Leopard or newer, devel/git-base now links against openssl instead which means it’s consistent with other platforms using pkgsrc as well as being able to build on older releases of Mac OS X. Unprivileged builds of this are still currently broken on Tiger as tar tries to set the group ownership of files to wheel, a patch to fix the issue is awaiting to be committed.

security/sudo now builds on Darwin (confirmed on Tiger PowerPC & Mavericks), the no_exec module doesn’t build on Darwin & is switched off in the Apple supplied build of sudo, this wasn’t switched off in pkgsrc & caused the build to fail. There are more options set in the Apple build to improve posture which are not set in pkgsrc version, that needs looking into further & is on the TODO list.

The new release of help2man committed last week broke on Tiger due to NLS being switched off & the new version introducing additional translations of info pages. The patch in pkg/49059 fixes things so shared libraries are taken care of as with Leopard & the package is built with NLS support.

Currently working on trying to get graphics/MesaLib building with XQuartz, the version shipped with Tiger is based on XFree86 & MesaLib fails to link libraries, macports seem to have some fixes related to building on Tiger which I’m hoping may fix some of the issues.

Will also be looking at devel/cmake as it’s currently broken on Tiger which means things such as mysql server cannot be built at the moment.

Through the existence of a directory called devel in /tmp which was owned by a user other than the the one pbulk runs under, some critical components such as autoconf & tradcpp did not build on the Mac Mini, this caused many builds to fail, that aside, the Mini has managed to build 1064 out of a queue of 2083 packages over the last week.
sevan.mit.edu is currently down (due to possible hardware issues) & awaiting a reboot.

Packages for PowerPC Mac OS X with pkgsrc

In pkgsrc there’s a facility which allows you to perform bulk builds of packages called pbulk.
Using this facility on a couple of donated systems I have started to generate packages for PowerPC OS X. Currently builds are performed on 32bit PowerPC Macs running OS X with pkgsrc-current. The binaries should in theory work on 64bit PowerPC systems and on Leopard but have not tested to confirm.
The packages are made available at sevan.mit.edu.
To utilise the packages on your system, fetch & uncompress the bootstrap archive which contains the pkgsrc tools.
curl -s http://sevan.mit.edu/packages/bootstrap.tar.gz | sudo tar -zxpf - -C /

Update your PATH & MANPATH variables
PATH=/usr/pkg/sbin:/usr/pkg/bin:$PATH
On Tiger
MANPATH=/usr/pkg/man can be declared in /usr/share/misc/man.conf
On Leopard use path_helper(8) and create a file in /etc/manpaths.d which just contains /usr/pkg/man.
This can also be extended to PATH by creating a file in /etc/paths.d/ containing one path element per line. This requires testing however as the impact is system wide.

Set PKG_PATH to http://sevan.mit.edu/packages/All/

Packages can then be installed using the pkg_add command, for example to install wget
pkg_add wget

This service is very much in its infancy & not stable yet, the current offering of packages is small but more packages are building on a daily basis albeit very slowly due to the age of the hardware.

If you’re interested in pkgsrc on Intel Macs try the Save OS X blog and Joyent packages which offer packages for Ilumos derivatives, Linux as well as OS X on Intel hardware.

Thanks to the generosity of David Brownlee, Thomas Brand & Justin Cormack for their generous donation of hardware.

Switching from Zevo to OpenZFS on OS X

I recently moved my last Mac from Greenbytes Zevo to OpenZFS on OS X, the reason for both sticking with Zevo & switching to OpenZFS were one and the same, CPU usage.
Prior to the development of OpenZFS on OS X, the two choices for using ZFS on OS X where Zevo or MacZFS, Zevo originally started out as a commercial product but switched to a freebie after Greenbytes picked it up. Zevo had much better integration with OS X e.g disk would be automatically mounted when connected to system just like any other disk with a supported file system and it supported a v28 of the filesystem whereas MacZFS supported a much older version.

When the OpenZFS on OS X development began just over a year ago, I ran the test builds that where made available, though these supported new features through feature flags it was very early days, attempting to scrub a zpool on a i7 MacBook Air with a USB 3 disk would spike the CPU for the duration and again the integration was still missing, you manually had to import & export pools. I continued to try newer builds on my MacBook Air but stuck with Zevo on my 2007 MacBook Pro.

The two things which where annoying about Zevo was that it was a dead end, development had stopped, the last version available wasn’t compatible¬†with¬†Mavericks available and its conservative memory setting meant that disk performance wasn’t that great, during playing audio files it would break to buffer audio in iTunes for example (luckily not in Serato as mid set would’ve been embarrassing).

As the MacBook Pro was running low on disk space I tried to move around 40GB of files in several chunks in parallel to my external USB3 disk & noticed the CPU pegged and fans started up with Zevo too. OpenZFS on OS X is fairly robust now (though still rough around the edges) so I decided to switch over.

The OpenZFS on OS X disk image comes with uninstall scripts for Zevo & though the main script was unable to detect the installed copy of Zevo, I was able to run the subsequent scripts individually to remove Zevo from my system and reboot (eject the disk containing the filesystem beforehand (export the zpool)).

The integration with OS X is still missing though it seems that on boot zpools are imported, I’ve not worked out if that’s because the system caches the state from previous boot or this is the preliminary support for auto mounting???

If you want to eject a disk, you still have to export the pool manually from terminal, pressing the eject button in finder will remove the disk icon but the filesystem is still mounted. That aside,¬†OpenZFS on OS X performed well, scrubbing the zpool on the 2007 MacBook Pro did not cause the CPU to spike at all, there is now a shorter delay in iTunes when starting to play a track but haven’t noticed any drops in audio yet, so things are looking positive.

Scrubbing the zpool on a 2007 17″ MacBook Pro with 4GB RAM

pool: tank
state: ONLINE
scan: scrub in progress since Fri Jul 25 18:58:48 2014
28.2G scanned out of 579G at 30.1M/s, 5h11m to go
0 repaired, 4.87% done
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
disk1s2 ONLINE 0 0 0

errors: No known data errors

All properties on the zpool I was using:
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Mon Jul 29 5:00 2013 -
tank used 579G -
tank available 1.22T -
tank referenced 579G -
tank compressratio 1.00x -
tank mounted yes -
tank quota none default
tank reservation none default
tank recordsize 128K default
tank mountpoint /tank default
tank sharenfs off default
tank checksum on default
tank compression off default
tank atime on default
tank devices on default
tank exec on default
tank setuid on default
tank readonly off default
tank zoned off default
tank snapdir hidden default
tank aclmode discard default
tank aclinherit restricted default
tank canmount on default
tank xattr on default
tank copies 1 default
tank version 5 -
tank utf8only on -
tank normalization formD -
tank casesensitivity sensitive -
tank vscan off default
tank nbmand off default
tank sharesmb off default
tank refquota none default
tank refreservation none default
tank primarycache all default
tank secondarycache all default
tank usedbysnapshots 0 -
tank usedbydataset 579G -
tank usedbychildren 4.48M -
tank usedbyrefreservation 0 -
tank logbias latency default
tank dedup off default
tank mlslabel none default
tank sync standard default
tank refcompressratio 1.00x -
tank written 579G -
tank logicalused 578G -
tank logicalreferenced 578G -
tank snapdev hidden default
tank com.apple.browse on default
tank com.apple.ignoreowner off default

Upgrading the zpool with OpenZFS on OS X
This system supports ZFS pool feature flags.

Successfully upgraded 'tank' from version 28 to feature flags.
pool_set_props
Enabled the following features on 'tank':
async_destroy
pool_set_props
empty_bpobj
pool_set_props
lz4_compress

12″ PowerBook G4 PT 4

Due to various factors, I’ve not had much of a chance to play with the PowerBook much this month, earlier this moth¬†a follow up to PR/48740 happened, requesting feedback on new changes which had been committed that I’ve not had a chance to test yet.
One thing I did do tonight was to re-flash the SuperDrive with a RPC-1 firmware image which turns the DVD drive region-free.
The firmware images are hosted on MacBook.fr and cover Macs all the way back to G3’s.
Flashing was straightforward though I could only re-flash with the version currently on the drive. It was not possible to flash a newer stock or region-free image on the drive.
Aside from the firmware on the DVD drive, Mac OS also tries to enforce region locking, the Region X utility can reset the Mac OS related setting regarding content region.

12″ PowerBook G4 PT 3

Since I last posted about dealing with pkgsrc on my PowerBook earlier this week, a patch has been committed which solves the linker issue on lang/gcc45 along with another fix related to how stripping of binaries is handled on Darwin. Unfortunately PR/48740 mentioned gcc44 to 46 suffer from the same issue but the patch has not been applied to gc44 or 46, I’m waiting to hear back from the committer.
One thing I forgot to mention in the previous post is that there is another issue with build process for GCC. There appears to be a deadlock issue where sh sits there chewing up CPU & context switching, at this point, aborting the build with & restarting again allows the build to continue.
Attaching to sh with gdb does not give any further insight as to what’s going on ūüôĀ

Apple’s Darwin according to GCC

From gcc’s target definitions for Darwin (Mac OS X) systems

/* The definitions in this file are common to all processor types
running Darwin, which is the kernel for Mac OS X. Darwin is
basically a BSD user layer laid over a Mach kernel, then evolved
for many years (at NeXT) in parallel with other Unix systems. So
while the runtime is a somewhat idiosyncratic Mach-based thing,
other definitions look like they would for a BSD variant. */

/* Although NeXT ran on many different architectures, as of Jan 2001
the only supported Darwin targets are PowerPC and x86. */

/* One of Darwin's NeXT legacies is the Mach-O format, which is partly
like a.out and partly like COFF, with additional features like
multi-architecture binary support. */

12″ PowerBook G4 PT 2

As I wrote the previous post, the PowerBook was attempting to compile lang/gcc48 from pkgsrc & since then I’ve still been attempting to build lang/gcc48 with varying levels of success which led me to branch out from trying to build GCC 4.8 to the other 4.x releases on pkgsrc.

In-between roasting the PowerBook I managed to obtain a re-writable CD, that allowed me to install OpenBSD on the PowerBook. Everything went smoothly apart from some bug with installer/documentation. The OpenBSD install was short-lived as I swapped the 5400RPM HDD for an 64GB SSD, the empty partition is there ready for reinstall but the GCC builds have consumed most of the time with the computer so I’ve not got around to reinstalling on the new disk.

TS64GPSD330:

Capacity: 59.63 GB
Model: TS64GPSD330
Revision: 20140121
Serial Number:
Removable Media: No
Detachable Drive: No
BSD Name: disk0
Protocol: ATA
Unit Number: 1
Socket Type: Internal
OS9 Drivers: No
S.M.A.R.T. status: Verified
Volumes:
Macintosh HD:
Capacity: 41.5 GB
Available: 26.21 GB
Writable: Yes
File System: Journaled HFS+
BSD Name: disk0s3
Mount Point: /

The laptop is now running with 1.25GB of RAM which has made a big difference, more than the SSD did, though the change is mainly visible in the apple supplied application binaries e.g System Preferences or Activity Monitor which don’t bounce on the dock whilst loading, click & it’s there, running.
About This Mac 1.25GB RAM
Trying to install a newer version of GCC from pkgsrc has been quite painful, build attempts are taking up to 20+ hours before failing, depending on which languages / options are enabled.

I reverted to attempting to building with only C & C++ language support to speed up the time to success/fail. This reduced the build time down to 8-10 hours, it then became apparent (a little quicker) that all GCC 4.x releases in pkgsrc fail to build on Mac OS X Tiger.
GCC 4.4 was the easiest to fix as the only thing that prevented the build of the C/C++ language support was a space between the -I flag & the path to headers to include which caused the linker to complain, this issues is taken care of in lang/gcc47 & gcc48 but the fix wasn’t retroactively applied to previous releases.
Attempting to build with GCC 4.5 & newer revealed further issues.
Thanks to the maintainer of TigerBrew, Misty De Meo who was able to provide hints for issues that need to be addressed in-order to build a more recent version of GCC on Tiger, having gone through the same problems when adding support in TigerBrew.

I’m not sure how many iterations other builds use but on pkgsrc gcc is built with 3 iterations of tests where binaries generated are compared at each iteration. The tests would fail on the third iteration, forcing dwarf2 format for debug data allowed the tests to succeed. As the G4 is a 32-bit PowerPC CPU, the build then failed when it came to 64-bit binaries, disabling multilib support resolved this issue, the build then failed as the linker & assembler bundled with XCode 2.5 were too old & missing functionality. Bug 52482 covers this issue.

gmake[4]: Entering directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libstdc++-v3' true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CC_FOR_TARGET=/usr/pkgsrc/lang/gcc48/work/build/./gcc/xgcc -B/usr/pkgsrc/lang/gcc48/work/build/./gcc/" "CFLAGS=-g -pipe -O2 -I/usr/pkg/include -I/usr/include" "CXXFLAGS=-g -pipe -O2 -I/usr/pkg/include -I/usr/include" "CFLAGS_FOR_BUILD=-pipe -O2 -I/usr/pkg/include -I/usr/include" "CFLAGS_FOR_TARGET=-g -pipe -O2 -I/usr/pkg/include -I/usr/include" "INSTALL=/usr/bin/install -c -o root -g wheel" "INSTALL_DATA=/usr/bin/install -c -o root -g wheel -m 644" "INSTALL_PROGRAM=/usr/bin/install -c -s -o root -g wheel -m 755" "INSTALL_SCRIPT=/usr/bin/install -c -o root -g wheel -m 755" "LDFLAGS=-L/usr/pkg/lib" "LIBCFLAGS=-g -pipe -O2 -I/usr/pkg/include -I/usr/include" "LIBCFLAGS_FOR_TARGET=-g -pipe -O2 -I/usr/pkg/include -I/usr/include" "MAKE=/usr/pkg/bin/gmake" "MAKEINFO=/usr/pkgsrc/lang/gcc48/work/.tools/bin/makeinfo --split-size=5000000 --split-size=5000000 " "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/pkg/gcc48" "infodir=/usr/pkg/gcc48/info" "libdir=/usr/pkg/gcc48/lib" "includedir=/usr/pkg/gcc48/include" "prefix=/usr/pkg/gcc48" "tooldir=/usr/pkg/gcc48/powerpc-apple-darwin8" "gxx_include_dir=/usr/pkg/gcc48/include/c++/" "AR=ar" "AS=/usr/pkgsrc/lang/gcc48/work/build/./gcc/as" "LD=/usr/pkgsrc/lang/gcc48/work/build/./gcc/collect-ld" "RANLIB=ranlib" "NM=/usr/pkgsrc/lang/gcc48/work/build/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" DO=all multi-do # /usr/pkg/bin/gmake gmake[4]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libstdc++-v3' gmake[3]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libstdc++-v3' gmake[2]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libstdc++-v3' Checking multilib configuration for libitm... gmake[2]: Entering directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm' /usr/pkg/bin/gmake all-recursive gmake[3]: Entering directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm' Making all in testsuite gmake[4]: Entering directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm/testsuite' gmake[4]: Nothing to be done for 'all'. gmake[4]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm/testsuite' gmake[4]: Entering directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm' /bin/sh ./libtool --mode=compile /usr/pkgsrc/lang/gcc48/work/build/./gcc/xgcc -B/usr/pkgsrc/lang/gcc48/work/build/./gcc/ -B/usr/pkg/gcc48/powerpc-apple-darwin8/bin/ -B/usr/pkg/gcc48/powerpc-apple-darwin8/lib/ -isystem /usr/pkg/gcc48/powerpc-apple-darwin8/include -isystem /usr/pkg/gcc48/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.8.2/libitm -I../../../gcc-4.8.2/libitm/config/powerpc -I../../../gcc-4.8.2/libitm/config/posix -I../../../gcc-4.8.2/libitm/config/generic -I../../../gcc-4.8.2/libitm -Wall -Werror -Wc,-pthread -g -pipe -O2 -I/usr/pkg/include -I/usr/include -MT sjlj.lo -MD -MP -MF .deps/sjlj.Tpo -c -o sjlj.lo ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S libtool: compile: /usr/pkgsrc/lang/gcc48/work/build/./gcc/xgcc -B/usr/pkgsrc/lang/gcc48/work/build/./gcc/ -B/usr/pkg/gcc48/powerpc-apple-darwin8/bin/ -B/usr/pkg/gcc48/powerpc-apple-darwin8/lib/ -isystem /usr/pkg/gcc48/powerpc-apple-darwin8/include -isystem /usr/pkg/gcc48/powerpc-apple-darwin8/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.8.2/libitm -I../../../gcc-4.8.2/libitm/config/powerpc -I../../../gcc-4.8.2/libitm/config/posix -I../../../gcc-4.8.2/libitm/config/generic -I../../../gcc-4.8.2/libitm -Wall -pthread -Werror -g -pipe -O2 -I/usr/pkg/include -I/usr/include -MT sjlj.lo -MD -MP -MF .deps/sjlj.Tpo -c ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S -fno-common -DPIC -o .libs/sjlj.o ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S:155:Invalid mnemonic 'FUNC' ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S:250:Invalid mnemonic 'CALL' ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S:259:Invalid mnemonic 'END' ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S:262:Invalid mnemonic 'HIDDEN' ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S:263:Invalid mnemonic 'FUNC' ../../../gcc-4.8.2/libitm/config/powerpc/sjlj.S:407:Invalid mnemonic 'END' Makefile:496: recipe for target 'sjlj.lo' failed gmake[4]: *** [sjlj.lo] Error 1 gmake[4]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm' Makefile:697: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm' Makefile:360: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build/powerpc-apple-darwin8/libitm' Makefile:16624: recipe for target 'all-target-libitm' failed gmake[1]: *** [all-target-libitm] Error 2 gmake[1]: Leaving directory '/usr/pkgsrc/lang/gcc48/work/build' Makefile:889: recipe for target 'all' failed gmake: *** [all] Error 2 *** Error code 2 Stop. bmake: stopped in /usr/pkgsrc/lang/gcc48 *** Error code 1

Apple provides updates as part of their open source initiative, cctools contain the as & ld sources but sadly with the move to intel & the startup of the Hackintosh scene Apple has made it a little difficult to build things, their first move was to stop generating the iso of Darwin builds & the documentation seems non-existent now. Funnily enough the legacy information on the iPhone jailbreak & Hackintosh scene seems to be the commonly available documentation, that is ofcourse after you’ve excluded bug reports from fink & mac/darwinports in your search results. The main problem with building the open-source components is the bespoke build mechanism which seems to have various issues with Mac OS X, mainly missing header files, with TigerBrew, they seem to work around this issue by using the headers from a newer version of OS X. Through my search for a solution I discovered the OpenDarwin project, the project repackaged the source for the open source Apple components around the GNU toolchain. A version is available in pkgsrc in emulators/darwin_lib though it’s intended for NetBSD/PowerPC to provide binary compatibility, sadly the version it attempts to build is older than the version available with XCode 2.5. The OpenDarwin site is broken & the project doesn’t appear to be in development but I was able to find a repository on Apples MacOS Forge for the OpenDarwin cctools which contained the cctools-758. This was sufficient to allow GCC 4.x to build successfully, AS & AS_TARGET variables need to be set to where the new version of as(1) installed from odcctools however. GCC 4.7 built successfully with C, C++, Fortran, Objective C, Objective C++ & Fortran support. The code is in a SVN repository, you can obtain precompiled binaries of old versions of svn from collab.net.
Using built-in specs. COLLECT_GCC=/usr/pkg/gcc47/bin/gcc COLLECT_LTO_WRAPPER=/usr/pkg/gcc47/libexec/gcc/powerpc-apple-darwin8/4.7.3/lto-wrapper Target: powerpc-apple-darwin8 Configured with: ../gcc-4.7.3/configure --enable-languages='c obj-c++ objc java fortran c++' --enable-shared --enable-long-long --with-local-prefix=/usr/pkg/gcc47 --enable-libssp --enable-threads=posix --with-boot-ldflags='-static-libstdc++ -static-libgcc -L/usr/pkg/lib ' --with-dwarf2 --disable-multilib --disable-nls --with-gmp=/usr/pkg --with-mpc=/usr/pkg --with-mpfr=/usr/pkg --with-ecj-jar=/usr/pkgsrc/distfiles/ecj-4.5.jar --enable-java-home --with-os-directory=darwin --with-arch-directory=powerpc --with-jvm-root-dir=/usr/pkg/java/gcc47 --with-java-home=/usr/pkg/java/gcc47 --with-system-zlib --enable-__cxa_atexit --with-gxx-include-dir=/usr/pkg/gcc47/include/c++/ --with-libintl-prefix=/usr/pkg --prefix=/usr/pkg/gcc47 --build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 --infodir=/usr/pkg/gcc47/info --mandir=/usr/pkg/gcc47/man Thread model: posix gcc version 4.7.3 (GCC)
While attempting to get things to build, lang/gcc48 was updated in pkgsrc and languages were separated out to individual packages with gcc48 becoming a wrapper around this, these changes are very much in their infancy and have issues which need to be addressed. As it currently stands, it’s not possible to build individual languages as there is ties which need to be removed e.g attempting to build lang/gcc48-cc++ will build in lang/gcc48-fortran. For me, the next step is to get these changes prepared correctly & submitted for inclusion in pkgsrc, for the duration of getting things to run I hard coded the paths for as(1) & defined the configure arguments globally, where as these changes are specific to Tiger & prior / 32-bit PowerPC specific. Then there’s dealing with odcctools, I’m not sure if it will require a new package or emulators/darwin_lib should be extended. emulators/darwin_lib introduces more than just odcctools hence my leaning towards a separate package. I also want to try out building from a RAM disk using Make RAM disk to see if build can be sped up any further. Since I wrote the previous article I found out how to set the location in F.lux, thanks to co-developer of F.lux, Michael Herf

It seems that some people opt to cross-compile for OS X on another platform, including macports developers (sorry, I didn’t make a note of the bug report where the developer explained building packages on Linux). iTerm 0.10 from the original project is now my terminal emulator with the Inconsolata font, the font smoothing isn’t that great on this machine when using white text on black background so I’ve opted for the opposite here & it’s working out well.
There is a MAC POWERPC ? blog which provides regular articles. I found an article on how to rebuild the PowerBook battery with new cells if it should fail.

Following the instructions from floodgap.com to update the curl-ca-bundle bundled with OS X I discovered that the version included in Tiger was from 2000!!

/usr/share/curl/curl-ca-bundle.crt - Last Modified: Thu Mar 2 09:32:46 CET 2000, These were automatically extracted from Netscape Communicator 4.72's certificate database (the file `cert7.db')

Building RetroBSD on Mac OS X

Earlier this week it was announced on the RetroBSD forum that the official repository had moved to GitHub. Along with the move came changes which fixed previous issues with the build so now it is possible to build a RetroBSD image on Mac OS X.

As covered in the RetroBSD installation document, I installed the required dependencies from MacPorts & used the prebuilt PIC32 toolchain to build RetroBSD.

port install bison byacc flex libelf

The compiler was uncompressed to /usr/local to keep it inline with the code base & reduce the number of changes need to get thing to build.

I’d previously installed the command line tools from within Xcode, while this had installed clang & the rest of the toolchain into /usr, I was missing /usr/include, installing the command line tools manually with xcode-select --install fixed this.

Kernel built from the SVN code base on Google Code:
2.11 BSD Unix for PIC32, revision 892M build 2:
Compiled 2014-03-29 by xxx@xxx:
/xxx/retrobsd/sys/pic32/max32-eth
cpu: 795F512L 80 MHz, bus 80 MHz
oscillator: XT crystal, PLL div 1:2 mult x20
console: tty0 (5,0)
sd0: port SPI2, select pin C14
sd0: type SDHC, size 15339520 kbytes, speed 13 Mbit/sec
phys mem = 128 kbytes
user mem = 96 kbytes
root dev = rd0a (0,1)
root size = 102400 kbytes
swap dev = rd0b (0,2)
swap size = 2048 kbytes
temp0: allocated 30 blocks
/dev/rd0a: 588 files, 8752 used, 93247 free
temp0: released allocation
Starting daemons: update cron

2.11 BSD UNIX (pic32) (console)

Kernel built from the git code base on GitHub:
2.11 BSD Unix for PIC32, revision G38 build 1:
Compiled 2014-04-19 by xxx@xxx:
/xxx/retrobsd/sys/pic32/max32-eth
cpu: 795F512L 80 MHz, bus 80 MHz
oscillator: XT crystal, PLL div 1:2 mult x20
console: tty0 (5,0)
sd0: port SPI2, select pin C14
sd0: type SDHC, size 15339520 kbytes, speed 13 Mbit/sec
phys mem = 128 kbytes
user mem = 96 kbytes
root dev = rd0a (0,1)
root size = 102400 kbytes
swap dev = rd0b (0,2)
swap size = 2048 kbytes
/dev/rd0a: 588 files, 8752 used, 93247 free
Starting daemons: update cron

2.11 BSD UNIX (pic32) (console)

12″ PowerBook G4

PowerBook G4
With the talk on Twitter & App.net about old computers I started to get nostalgic. I had cleared out most of my collection back in 2012 & been resisting the urge to resume hoarding again largely, having successfully put off the purchase of a Ubiquiti EdgeRouter Lite to run FreeBSD on, I remembered that I was offered a G4 PowerBook a few months back which I turned down. It was still available if I wanted to take it, which made very happy. a 12″PowerBook6,4 that I’d assumed it was going to be a 15″ model. I’ve been playing about with it for the past couple of days, wiping the pre-installed copy of Leoapard & going through the Panther to Tiger path.

20140404-022224.jpg
The system is now running 10.4.11, patching was a lot of fun, java update after java update, pretty sure it didn’t seem that bad at the time.
20140404-020714.jpg
It was interesting to see that there was no iTunes update made available, having to manually fetch v9.2.1 from kb DL1056. Safari was updated to v4.1.3.

With no more updates on offer from the software update facility I disabled the java & macromedia plugins by moving them out of /Library/Internet Plug-ins & /Library/Application Support.

Going back to Tiger was a mixture of pleasure & pain, visually, I much prefer the brighter white look of aqua, as opposed to the grey theme which introduced in Leopard. Terminal.app in Tiger is not that great, font smooth is particularly poor, I may have to resort to sourcing a copy of the original iTerm. Plan9 from userspace built without issues using gcc from XCode 2.5, but I guess finder doesn’t like something about the bundled transparent icon of Glenda on the dock as it shows up with a white background & though acme launches correctly, the icon continues to bounce on the dock.
20140404-020905.jpg
F.lux 1.1 is the last supported PowerPC build which runs on Tiger, no support for UK in location settings of this build.
TenFourFox takes the place of Firefox as an up to date, maintained version for the PowerPC Mac’s. Python was updated to 2.7.6 using a package straight from python.org.

There is a PowerPC Software site, which contains links to the last builds of popular software which supported the PowerPC Mac’s.

Mercurial & Ruby built successfully from source, pkgsrc also bootstrapped without any issue, the system is currently building GCC 4.8 from pkgsrc.
Needed to declare MACOSX_DEPLOYMENT_TARGET=10.4 otherwise the build process would fail with ld: flag: -undefined
dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment
variable set to: 10.1

The system currently has 512MB of RAM & a 74GB HDD, 40GB allocated to OS X & the remaining intended for use with OpenBSD, will have to netinstall OpenBSD as I don’t have any blank CD’s with me, no USB hub, the USB ports don’t provide sufficient power to run a Zalman Virtual CD and I suspect the system is unable to boot from USB anyway. Been looking on Amazon for IDE SSD drives but probably will increase the RAM first.
20140404-020959.jpg

20140404-022158.jpg