Am 09.02.2012 17:20, schrieb Walter Bright: > On 2/9/2012 1:37 AM, Sönke Ludwig wrote: >> I have a project that we actually plan to use in production in the >> company for >> which I work. They still require 10.5 support for their products so >> removing >> that support would make for a very bad situation here. >> >> But it should be possible to get a 10.5 retail DVD and install it >> inside a VM.. >> I actually planned to do exactly this to support 10.5 nightbuilds for >> my own D >> stuff. >> >> If support should be dropped anyway, are the issues only build-related >> so that >> e.g. gdc would still continue work on 10.5 without further work? > > > Would it also be possible for you to: > > 1. debug what has gone wrong with the 10.5 support? I'll be happy to > fold in any resulting patches. > > 2. provide a remote login shell so we can figure it out? > > 3. use git bisect to determine which change broke it?
I was able to test on a Mac Mini with 10.5 today (setting up a virtual machine did not work without downloading disk images over torrent or similar stuff and v4.1.1 of vmware fusion does not allow non-server installations anymore). My findings were: - stock DMD did not run because it is compiled for 64-bit while the system is 32-bit only - compiling on a 10.6 machine with stock DMD caused a fatal dyld error at application startup on the 10.5 machine (for a simple hello world app) - compiling a fresh DMD on the 10.5 machine from git seems to yield working executables So either the problem is just a build setup issue or it was something I didn't test (I tested writefln() as in bug 4854). Is there a standard way to build the DMD+druntime+phobos package so I can simulate the original build process? Right now I just compiled each of those separately using "make posix.mk" without any further options. Minor note: the version check in dmd/source/posix.mk to select the OS X SDK does not work on 10.5 and it selects the 10.6 SDK.
