PowerPC Support on Mac OS 10.5.8

Question

PowerPC Support on Mac OS 10.5.8

smaboshe opened this issue 12 years ago · comments

Silumesii Maboshe commented 12 years ago

Hello,

With reference to: guard/guard#206 (comment)

I'm running rb-fsevent on a PowerPC and Mac OS 10.5.8. The CPU does not seem to be supported. If you have any suggestions on how I can get it to work or some workaround tools I could use I'd be very grateful.

If you need help compiling code etc, let me know.

Thanks in advance.

Travis Tilley · Answer 1 · Sat Feb 04 2012 01:19:06 GMT+0800 (China Standard Time)

I will be able to get on this late tonight or tomorrow. What time(s) would you be available to work with? AIM or another IM service would be useful.

Note that while I believe -something- should work for everyone, the main x86/x86-64 binary is the focus and dropping 10.5 support there would make things quite a bit nicer (coding/maintenance-wise for me, personally). That doesn't mean that the code can't support all scenarios for recompilation by whoever wants to... just that they won't be the focus of effort and without a PPC box to test, or a 10.5 box to test, they may decay and/or break over time...

ANYWAYS! The goal of any open source project is to solve problems. Lets attack yours. ^_^b

Silumesii Maboshe · Answer 2 · Sat Feb 04 2012 03:16:25 GMT+0800 (China Standard Time)

Thanks!! Just about to drop you a message to talk scheduling.

Travis Tilley · Answer 3 · Thu Feb 09 2012 15:15:26 GMT+0800 (China Standard Time)

ZOMG I'd like to refer you to: Homebrew/legacy-homebrew#6827 (comment)

...was attempting to make it even more painless by just having a singular binary, but managed to completely break my devchain. -_-

Silumesii Maboshe · Answer 4 · Thu Feb 09 2012 15:27:23 GMT+0800 (China Standard Time)

OUCH!

Hope you are able to get up and running again soon. I was never able to jump on the homebrew bandwagon. I'd need to upgrade my computer for that ... :)

Silumesii Maboshe · Answer 5 · Mon Apr 09 2012 15:08:35 GMT+0800 (China Standard Time)

@ttilley I've been able to get my test environment up to scratch again using rb-fsevent-legacy: http://rubygems.org/gems/rb-fsevent-legacy

Travis Tilley · Answer 6 · Tue Apr 10 2012 02:28:04 GMT+0800 (China Standard Time)

@smaboshe @stephenprater - I've managed to get a custom build of clang that includes support for x86, x86_64, ppc, ppc64, and arm. I've also seen how ridiculously easy it is to create a custom xcode4 compiler plugin (though running the analyzer will never use the custom compiler). That just leaves three problems:

hacked together SDK install that works as intended with clang and not gcc (or libgcc)
building against different SDKs for different architectures and still having that work in a universal binary
making damn sure anything depending on 10.6 or later is wrapped in an ifdef

Then, using the custom clang build and xcode plugin, a single binary can be built that works everywhere and even if you're on PPC you'll get a current version of rb-fsevent.

...I'll make a custom homebrew formula today that installs the custom clang and xcode4 plugin.

Prater · Answer 7 · Tue Apr 10 2012 02:40:32 GMT+0800 (China Standard Time)

@smaboshe you can also use the guard-legacy gem which will monkey-patch in that rb-fsevent-legacy correctly - that code is very much in a "works for me" kind of state, so let me know if you run into any problems with it - I will probably stop maintaing it when (if) I get a new machine.

Prater · Answer 8 · Tue Apr 10 2012 02:48:55 GMT+0800 (China Standard Time)

@ttilley cool, thanks.

Travis Tilley · Answer 9 · Tue Apr 10 2012 10:46:57 GMT+0800 (China Standard Time)

my current build script (homebrew formula was a PITA with multiple maybe/maybe-not repo urls):

#!/usr/bin/env bash

SVN_BASE='http://llvm.org/svn/llvm-project'
LLVM_SVN='/llvm/trunk'
CLANG_SVN='/cfe/trunk'
POLLY_SVN='/polly/trunk'
COMPILER_RT_SVN='/compiler-rt/trunk'
LIBCXX_SVN='/libcxx/trunk'


export BASE=`pwd`
export LLVM_SRC="${BASE}/llvm"
export CLANG_SRC="${LLVM_SRC}/tools/clang"
export POLLY_SRC="${LLVM_SRC}/tools/polly"
export COMPILER_RT_SRC="${LLVM_SRC}/projects/compiler-rt"
export LIBCXX_SRC="${LLVM_SRC}/projects/libcxx"
export CLOOG_SRC="${BASE}/cloog_src"
export LLVM_BUILD="${BASE}/llvm-build"
export LLVM_INSTALL="/usr/local/Cellar/llvm/HEAD"
export CLOOG_INSTALL="${BASE}/cloog_install"


svn checkout "${SVN_BASE}${LLVM_SVN}" "${LLVM_SRC}"
svn checkout "${SVN_BASE}${CLANG_SVN}" "${CLANG_SRC}"
# svn checkout "${SVN_BASE}${POLLY_SVN}" "${POLLY_SRC}"
svn checkout "${SVN_BASE}${COMPILER_RT_SVN}" "${COMPILER_RT_SRC}"
svn checkout "${SVN_BASE}${LIBCXX_SVN}" "${LIBCXX_SRC}"

# ${POLLY_SRC}/utils/checkout_cloog.sh ${CLOOG_SRC}
# pushd ${CLOOG_SRC}
# ./configure --prefix=${CLOOG_INSTALL}
# make
# make install
# popd

sed -ie 's|.*root:wheel.*||g' "${LLVM_SRC}/projects/libcxx/Makefile"

mkdir -p "${LLVM_BUILD}"
pushd "${LLVM_BUILD}"

${LLVM_SRC}/configure \
    --prefix="${LLVM_INSTALL}" \
    --disable-polly \
    --enable-optimized \
    --with-optimize-option="-O2" \
    --with-extra-options="-DDISABLE_DEFAULT_STRICT_ALIASING" \
    --with-extra-ld-options="-fno-pie" \
    --disable-assertions \
    --disable-expensive-checks \
    --disable-bindings \
    --enable-targets=x86,x86_64,arm,powerpc \
    --enable-jit \
    --enable-libcpp \
    --disable-timestamps \
    --without-llvmgcc --without-llvmgxx
    # --with-cloog="${CLOOG_INSTALL}" --with-isl="${CLOOG_INSTALL}"

make \
    UNIVERSAL=1 UNIVERSAL_ARCH="i386 x86_64 ppc" \
    KEEP_SYMBOLS=1 CLANG_IS_PRODUCTION=1 \
    CLANG_REPOSITORY_STRING="trunk" \
    CLANG_VENDOR="Homebrew" \
    CLANG_VENDOR_UTI="homebrew.mxcl.compilers.llvm.clang" \
    LLVM_VERSION_INFO="LLVM 3.1svn" LLVM_LTO_VERSION_OFFSET=3000 && \
make install

popd

That's going to take forever and a day to build...

My local xcode4 plugin essentially follows the info here: http://belkadan.com/blog/2011/07/Using-Clang-from-SVN-in-Xcode/
HOWEVER, I am not messing with the xcode4 app. I am instead installing the plugin to ~/Library/Application Support/Developer/Shared/Xcode/Plug-ins, which is also on the plugin lookup path. I'm not sure if this is on the xcode3 plugin path, but similar techniques could be used to get yourself a sane-ish clang install usable from xcode3.

I guess we'll see how well this all worked out at some point tomorrow or the day after (wife's b-day tomorrow).

Travis Tilley · Answer 10 · Tue Apr 17 2012 10:41:45 GMT+0800 (China Standard Time)

DEAR GOD THE PAIN. THE PAIIIIIIIIIIIIN...........

Anyways, PPC people... give my branch of rb-fsevent a shot (ttilley/rb-fsevent) or just replace the binary after installing rb-fsevent proper using: https://github.com/ttilley/rb-fsevent/blob/master/bin/fsevent_watch

Travis Tilley · Answer 11 · Tue Apr 17 2012 10:50:25 GMT+0800 (China Standard Time)

so yeah. I have a makefile set up so that I can build x86_64, i386, and ppc seperately on different machines and then cram them together into a universal fat mach-o binary. however, I seem to be having issues with the makefile's dependencies so i'm going to say screw it and replace it with a rakefile that makes more sense before committing it.

The makefile:

ifndef ARCH
ARCH = $(shell uname -m)
endif

ifndef config
config = debug
endif
export config

ifndef verbose
SILENT = @
endif

PROJECT_VERSION = 0.1.1
PATH_OF_COMMAND = /usr/bin/xcrun -find
CC = $(shell $(PATH_OF_COMMAND) clang)
XCODEBUILD = /usr/bin/xcodebuild
LIPO = /usr/bin/lipo
SW_VERS = /usr/bin/sw_vers
CHMOD = /bin/chmod
USER = $(shell whoami)
MACOS_VERSION = $(shell sw_vers -productVersion)
MACOS_BUILD = $(shell sw_vers -buildVersion)
OBJROOT = obj/$(config)/$(ARCH)
BINARY = fsevent_watch

OBJECTS := \
    $(OBJROOT)/TSICTString.o \
    $(OBJROOT)/cli.o \
    $(OBJROOT)/compat.o \
    $(OBJROOT)/main.o

ARCH_BINARIES := \
    obj/$(config)/x86_64/$(BINARY) \
    obj/$(config)/i386/$(BINARY)

SDK = macosx
SDK_PATH = $(shell $(XCODEBUILD) -version -sdk $(SDK) Path)
SDK_VERSION = $(shell $(XCODEBUILD) -version -sdk $(SDK) SDKVersion)
SDK_FULL_VERSION = $(shell $(XCODEBUILD) -version -sdk $(SDK) ProductUserVisibleVersion)
SDK_BUILD = $(shell $(XCODEBUILD) -version -sdk $(SDK) ProductBuildVersion)
SDK_NAME = macosx$(SDK_VERSION)
BUILD_MACHINE_OS_BUILD = $(shell $(SW_VERS) -buildVersion)
BUILD_MACHINE_OS_VERSION = $(shell $(SW_VERS) -productVersion)
MACOSX_DEPLOYMENT_TARGET = $(SDK_VERSION)

SYSTEM_LIBRARY_DIR = $(SDK_PATH)/System/Library
LOCAL_LIBRARY_DIR = $(SDK_PATH)/Library
ARCH_FLAG = -arch $(ARCH)
ISYSROOT_FLAG = -isysroot $(SDK_PATH)
VERSION_MIN_FLAG = -mmacosx-version-min=$(MACOSX_DEPLOYMENT_TARGET)
OPTIMIZATION_LEVEL = 0
DEFINES = -DPROJECT_VERSION="$(PROJECT_VERSION)" -DCLI_NAME="\"$(BINARY)\"" -DNS_BUILD_32_LIKE_64 -DNS_BLOCK_ASSERTIONS -DOS_OBJECT_USE_OBJC=0 -DMACOSX_DEPLOYMENT_TARGET=$(MACOSX_DEPLOYMENT_TARGET) -DOPTIMIZATION_LEVEL=$(OPTIMIZATION_LEVEL) -DVERSION_INFO_BUILDER=$(USER) -DMAC_OS_X_PRODUCT_BUILD_VERSION=$(BUILD_MACHINE_OS_BUILD) -DMAC_OS_X_VERSION_ACTUAL=$(BUILD_MACHINE_OS_VERSION) -DSDK_PRODUCT_BUILD_VERSION=$(SDK_BUILD) -DSDK_NAME=$(SDK_NAME)
INCLUDES =
CPPFLAGS = -MMD -MP $(DEFINES) $(INCLUDES)
FEATURE_FLAGS = -fstrict-aliasing -fconstant-cfstrings -fpascal-strings
WARNING_FLAGS = -Wall -Wextra -Wno-trigraphs -Wstrict-overflow=4 -Wstrict-aliasing -Wsign-compare -Wshorten-64-to-32 -Wpointer-sign -Wnewline-eof
FRAMEWORK_PATH_FLAGS = -F$(SYSTEM_LIBRARY_DIR)/Frameworks -F$(LOCAL_LIBRARY_DIR)/Frameworks
FRAMEWORK_FLAGS = -framework CoreFoundation -framework CoreServices
CFLAGS = $(ARCH_FLAG) $(ISYSROOT_FLAG) $(VERSION_MIN_FLAG) $(FRAMEWORK_PATH_FLAGS) -std=gnu99 -pipe $(FEATURE_FLAGS) $(WARNING_FLAGS) -O$(OPTIMIZATION_LEVEL)
LDFLAGS = $(ARCH_FLAG) $(ISYSROOT_FLAG) $(VERSION_MIN_FLAG) $(FRAMEWORK_PATH_FLAGS) $(FRAMEWORK_FLAGS) -sectcreate __TEXT __info_plist $(OBJROOT)/Info.plist


ifeq ($(config),"debug")
OPTIMIZATION_LEVEL = 0
DEFINES += -DDEBUG -DDEBUG_$(USER)
CFLAGS += -g -fcatch-undefined-behavior -ftrapv -fverbose-asm
endif

ifeq ($(config),"release")
OPTIMIZATION_LEVEL = s
DEFINES += -DNDEBUG
endif

ifeq ($(ARCH),"ppc")
MACOSX_DEPLOYMENT_TARGET = 10.5
endif

ifndef CC_i386
CC_i386 = $(CC)
endif
export CC_i386

ifndef CC_x86_64
CC_x86_64 = $(CC)
endif
export CC_x86_64

ifndef CC_ppc
CC_ppc = $(CC)
endif
export CC_ppc

.PHONY: showvar build clean universal

all: build

showvar:
    @echo $($(VAR))

clean:
    $(SILENT) rm -rf obj

$(OBJROOT):
    @echo Creating $(OBJROOT)
    $(SILENT) mkdir -p "$(OBJROOT)"


ifeq ($(ARCH),"universal")

build: $(OBJROOT)/$(BINARY)

$(OBJROOT)/$(BINARY): $(OBJROOT)
    @echo Creating universal binary...
    $(SILENT) $(LIPO) -create $(ARCH_BINARIES) -output $@
    $(SILENT) $(CHMOD) a+x $@

else

build: $(OBJROOT) $(OBJROOT)/Info.plist $(OBJROOT)/$(BINARY)

$(OBJROOT)/Info.plist: Info.plist
    @echo Processing $@...
    $(SILENT) $(CC_$(ARCH)) -E -P -x c -Wno-trigraphs -traditional -CC $(CPPFLAGS) $< -o $@.out
    $(SILENT) xmllint --format --recover $@.out | sed -E -e '/<string>/ s/" "//g' -e '/<string>/ s/"//g' > $@

$(OBJROOT)/%.o: fsevent_watch/%.c
    @echo Compiling $@...
    $(SILENT) $(CC_$(ARCH)) $(CFLAGS) $(CPPFLAGS) -c $< -o $@

$(OBJROOT)/$(BINARY): $(OBJECTS)
    @echo Linking $@...
    $(SILENT) $(CC_$(ARCH)) $(LDFLAGS) $(OBJECTS) -o $@
    $(SILENT) $(CHMOD) a+x $@

endif

I also edited the Info.plist that gets embedded into the image for each arch, since things like "xcode version" aren't exactly relevant when you're not building with xcode. Content is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<!--
#include "fsevent_watch/defines.h"
-->
<plist version="1.0">
  <dict>
    <key>CFBundleExecutable</key>
    <string>fsevent_watch</string>
    <key>CFBundleIdentifier</key>
    <string>com.teaspoonofinsanity.fsevent_watch</string>
    <key>CFBundleName</key>
    <string>fsevent_watch</string>
    <key>CFBundleVersion</key>
    <string>PROJECT_VERSION</string>
    <key>LSMinimumSystemVersion</key>
    <string>MACOSX_DEPLOYMENT_TARGET</string>
    <key>DTSDKBuild</key>
    <string>SDK_PRODUCT_BUILD_VERSION</string>
    <key>DTSDKName</key>
    <string>SDK_NAME</string>
    <key>BuildMachineOSBuild</key>
    <string>MAC_OS_X_PRODUCT_BUILD_VERSION</string>
    <key>BuildMachineOSVersion</key>
    <string>MAC_OS_X_VERSION_ACTUAL</string>
    <key>FSEWCompiledAt</key>
    <string>COMPILED_AT</string>
    <key>FSEWCompiler</key>
    <string>COMPILER</string>
    <key>FSEWCompilerVersion</key>
    <string>__VERSION__</string>
    <key>FSEWCompilerTargetCPU</key>
    <string>TARGET_CPU</string>
    <key>FSEWOptimizationLevel</key>
    <string>OPTIMIZATION_LEVEL</string>
    <key>FSEWVersionInfoBuilder</key>
    <string>VERSION_INFO_BUILDER</string>
    <key>SystemVersionMaxAllowed</key>
    <string>__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__</string>
  </dict>
</plist>

Due to the nature of the C preprocessor and various defines being C string syntax, post-processing of the, erm... processed Info.plist is required to make it not be fugly. The sed command is above in the makefile.

Travis Tilley · Answer 12 · Tue Jan 01 2013 02:12:57 GMT+0800 (China Standard Time)

the latest rb-fsevent replaces the xcode project with a rakefile. cd into ext and run:
rake ppc replace_exe

...let me know if that actually works, because I could not get clang-3.2 to produce valid assembly no matter what I did and I don't have a PPC mac to test anything on. You may need to call with a few variables set, like:

CC=/path/to/known/good/compiler MACOS_DEPLOYMENT_TARGET=10.5 CFLAGS='-Wall' rake ppc replace_exe

Travis Tilley · Answer 13 · Tue Jan 01 2013 07:04:26 GMT+0800 (China Standard Time)

ok, with gcc-4.2 from xcode 3.2.6 it works for ppc on 10.5 via:

MACOSX_DEPLOYMENT_TARGET="10.5" CC=/usr/bin/gcc-4.2 ARCHFLAGS="-arch x86_64 -arch i386 -arch ppc -arch ppc64" rake replace_exe

...giving you the universal all-arch binary that used to be oh so easy to build.

I think i'm going to just note this setup in the readme and try not to break it, rather than fully support it. Hell, my current installation of xcode can't even target 10.6 nevermind 10.5 ppc... and clang-3.2 with integrated assembler doesn't seem to produce valid assembly for ppc (the integrated assembler is important as otherwise it would have to call out to the system gcc, which probably won't support ppc asm either unless you're using xcode 3.2.6 to begin with).

Travis Tilley · Answer 14 · Tue Jan 01 2013 07:35:47 GMT+0800 (China Standard Time)

README updated. closing.