10.6 Snow Leopard PowerPC Development

[Jazzzny]

The Darwinbuild backend which used to be hosted on http://src.macosforge.org/Roots/ was completely nuked a few years ago. Without this fileserver, Darwinbuild can't download anything. I've had some luck switching it to point to the Archive.org URL, but the file archive is incomplete there so a lot of projects still don't build.

 

[barracuda156]

The Darwinbuild backend which used to be hosted on http://src.macosforge.org/Roots/ was completely nuked a few years ago. Without this fileserver, Darwinbuild can't download anything. I've had some luck switching it to point to the Archive.org URL, but the file archive is incomplete there so a lot of projects still don't build.

I have moved sources to macos-powerpc.org/Projects, and here is the port:

darwinbuild: fix the build · barracuda156/powerpc-ports@71bc5f7

Fork of MacPorts ports for macOS PowerPC. Contribute to barracuda156/powerpc-ports development by creating an account on GitHub.

github.com

1. On 10.6.8 drop the last patch (10a190 hack).
2. `0004-darwinbuild.in-fix-for-renamed-sources-from-Apple-re.patch` fixes extract, but not sure it is enough. Problem: Apple renamed sources in a retarded way, `${name}-${name}-${version}`, while Darwinbuild expects `${name}-${version}`.
3. As of now, it fails to build roots both on powerpc natively and in 10.6.8 x86_64, with a bunch of errors:

xcodebuild: 'relpath' not found
/Developer/usr/bin/xcodebuild fails with 512 - Unknown error: 512
make[5]: execvp: /Users/svacchanda/10A432/BuildRoot/SourceCache/xnu/xnu-xnu-1456.1.26: Permission denied

I do not know what that means, please tell us if you know. But it seems the app is functional, just something in the setup is not right.

P. S. Build with `-nochroot`, since we do not yet have roots with ppc included.

 

[ChrisCharman]

I have moved sources to macos-powerpc.org/Projects, and here is the port:

darwinbuild: fix the build · barracuda156/powerpc-ports@71bc5f7

Fork of MacPorts ports for macOS PowerPC. Contribute to barracuda156/powerpc-ports development by creating an account on GitHub.

github.com

1. On 10.6.8 drop the last patch (10a190 hack).
2. `0004-darwinbuild.in-fix-for-renamed-sources-from-Apple-re.patch` fixes extrat, but not sure it is enough. Problem: Apple renamed sources in a retarded way, `${name}-${name}-@{version}`, while Darwinbuild expects `${name}-@{version}`.
3. As of now, it fails to build roots both on powerpc natively and in 10.6.8 x86_64, with a bunch of errors:

xcodebuild: 'relpath' not found
/Developer/usr/bin/xcodebuild fails with 512 - Unknown error: 512
make[5]: execvp: /Users/svacchanda/10A432/BuildRoot/SourceCache/xnu/xnu-xnu-1456.1.26: Permission denied

I do not know what that means, please tell us if you know. But it seems the app is functional, just something in the setup is not right.

P. S. Build with `-nochroot`, since we do not yet have roots with ppc included.

Relpath is in bootstrap commands source tarball @barracuda156

 

[barracuda156]

Relpath is in bootstrap commands source tarball @barracuda156

Wonder why darwinbuild does not install that one first then.
Anyway, darwinbuild itself works:

====== Installing config =====
/usr/bin/install -m 0755 -o root -g wheel -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/bin
/usr/bin/install -m 0555   -o root   -g wheel   -s /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/config /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/bin
make[3]: Nothing to be done for `after_install'.
Compressing man pages for config...
/Developer/Makefiles/bin/compress-man-pages.pl -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root /usr/share/man
TargetConfig: MacOSX
if [ ! -f "/Users/svacchanda/10A432/BuildRoot/SourceCache/bootstrap_cmds/bootstrap_cmds-bootstrap_cmds-72/Makefile" ]; then make install_source; fi
===== Building relpath RELEASE =====
/Developer/usr/bin/cc -arch ppc -arch i386 -g -Os -pipe -Wall -Werror -mdynamic-no-pic -I/Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.obj/relpath -c -o /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.obj/relpath/relpath.o relpath.c
===== Linking relpath RELEASE =====
/Developer/usr/bin/cc -arch ppc -arch i386            -dead_strip -o /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/relpath \
         /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.obj/relpath/relpath.o
dsymutil --out /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/relpath.dSYM \
        /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/relpath || true
====== Installing relpath =====
/usr/bin/install -m 0755 -o root -g wheel -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/local/bin
/usr/bin/install -m 0555   -o root   -g wheel   -s /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/relpath /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/local/bin
make[3]: Nothing to be done for `after_install'.
Compressing man pages for relpath...
/Developer/Makefiles/bin/compress-man-pages.pl -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root /usr/share/man
TargetConfig: MacOSX
if [ ! -f "/Users/svacchanda/10A432/BuildRoot/SourceCache/bootstrap_cmds/bootstrap_cmds-bootstrap_cmds-72/Makefile" ]; then make install_source; fi
===== Building decomment RELEASE =====
/Developer/usr/bin/cc -arch ppc -arch i386 -g -Os -pipe -Wall -mdynamic-no-pic -I/Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.obj/decomment -c -o /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.obj/decomment/decomment.o decomment.c
===== Linking decomment RELEASE =====
/Developer/usr/bin/cc -arch ppc -arch i386            -dead_strip -o /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/decomment \
         /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.obj/decomment/decomment.o
dsymutil --out /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/decomment.dSYM \
        /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/decomment || true
====== Installing decomment =====
/usr/bin/install -m 0755 -o root -g wheel -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/local/bin
/usr/bin/install -m 0555   -o root   -g wheel   -s /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.sym/decomment /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/local/bin
make[3]: Nothing to be done for `after_install'.
Compressing man pages for decomment...
/Developer/Makefiles/bin/compress-man-pages.pl -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root /usr/share/man
===== Building bootstrap_cmds RELEASE =====
====== Installing bootstrap_cmds =====
/usr/bin/install -m 0755 -o root -g wheel -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root//usr/bin
Installing man pages for bootstrap_cmds...
/usr/bin/install -m 0444 -o root -g wheel vers_string.1 /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root/usr/share/man/man1
/usr/bin/install -m 0755 -o root -g wheel -d "/Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root"/usr/bin
/usr/bin/install -m 0555   -o root   -g wheel vers_string.sh "/Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root"/usr/bin/vers_string
Compressing man pages for bootstrap_cmds...
/Developer/Makefiles/bin/compress-man-pages.pl -d /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root /usr/share/man
gzip -f -n /Users/svacchanda/10A432/BuildRoot/private/var/tmp/bootstrap_cmds/bootstrap_cmds-72.root/usr/share/man/man1/vers_string.1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 BUILD TIME: 0h 0m 13s
EXIT STATUS: 0
bootstrap_cmds - 7 files registered.
                                         40755 0 0 0 ./usr
                                         40755 0 0 0 ./usr/bin
95111f52a2e6bd7c38693bd1b9633d13f2f0d284 100555 0 0 177240 ./usr/bin/config
772f765ce3609f295b9eea0e22b4b0bbe500816e 100555 0 0 7777 ./usr/bin/mig
8ec22631ea203aa0d8eee67e9607e94908ea4a73 100555 0 0 3299 ./usr/bin/vers_string
                                         40755 0 0 0 ./usr/libexec
ca34128f28a408a467368c09643145245875b225 100555 0 0 350656 ./usr/libexec/migcom
                                         40755 0 0 0 ./usr/local
                                         40755 0 0 0 ./usr/local/bin
7f548edabc73665ed83102e7e6e91cc7d75c09a2 100555 0 0 25328 ./usr/local/bin/decomment
73504a158c68b5cd10326c5ceb75950d8c29b499 100555 0 0 25824 ./usr/local/bin/relpath
                                         40755 0 0 0 ./usr/share
                                         40755 0 0 0 ./usr/share/man
                                         40755 0 0 0 ./usr/share/man/man1
953428d493387696f6cbadacdcdaf37d7b2f839a 100444 0 0 626 ./usr/share/man/man1/vers_string.1.gz

bash-3.2# file /Users/svacchanda/10A432/Roots/bootstrap_cmds/bootstrap_cmds-72.root\~1/usr/local/bin/relpath 
/Users/svacchanda/10A432/Roots/bootstrap_cmds/bootstrap_cmds-72.root~1/usr/local/bin/relpath: Mach-O universal binary with 2 architectures
/Users/svacchanda/10A432/Roots/bootstrap_cmds/bootstrap_cmds-72.root~1/usr/local/bin/relpath (for architecture ppc7400):    Mach-O executable ppc
/Users/svacchanda/10A432/Roots/bootstrap_cmds/bootstrap_cmds-72.root~1/usr/local/bin/relpath (for architecture i386):    Mach-O executable i386

So presumably everything can be built that way now. I will test a few builds and then update on this.

 

[barracuda156]

Upd on Darwinbuild:

A number of projects compile normally with no hacks (this is not an exhaustive list, it is just what I tried minus those which failed):

apr
architecture
autoconf
automake
awk
basic_cmds
bc
bison
bootstrap_cmds
bsdmake
bzip2
CarbonHeaders
CoreOSMakefiles
CPANInternal
cscope
developer_cmds
diffstat
disklabel
expat
file
files
flex
gcc_select
glibtool
gm4
gnudiff
gnumake
gnuzip
gperf
groff
less
Libc_headers
Libcpp_kext
libedit
libevent
libffi
libiconv
libkxld
libmd
Libnotify
libpcap
Librpcsvc
libutil
man
ncurses
patch_cmds
pb_makefiles
pcre
system_config
SystemStubs
TargetConfig
TargetConfig_headers
texi2html
texinfo
UserNotification
uucp
xar
xelf

All are built as ppc+i386+x86_64.

A number of projects fail, and unfortunately it is not immediately clear, whether dependencies are needed, or headers should be installed first, or just code is broken and should be patched.

In any case, the approach seems reasonably workable; definitely it would take me longer to build all these manually (whether directly or via custom portfiles). But if all these were implemented via MacPorts, life would be easier, since MacPorts handles dependencies correctly (as long as those are specified), while Darwinbuild seems to expect you gonna guess the right order, and you are on your own. Compare how much easier it is to build `libdispatch` via my portfile. (But no, I am not gonna rewrite everything into portfiles, it is a lot of work.)

 

[ChrisCharman]

Upd on Darwinbuild:

A number of projects compile normally with no hacks (this is not an exhaustive list, it is just what I tried minus those which failed):

apr
architecture
autoconf
automake
awk
basic_cmds
bc
bison
bootstrap_cmds
bsdmake
bzip2
CarbonHeaders
CoreOSMakefiles
CPANInternal
cscope
developer_cmds
diffstat
disklabel
expat
file
files
flex
gcc_select
glibtool
gm4
gnudiff
gnumake
gnuzip
gperf
groff
less
Libc_headers
Libcpp_kext
libedit
libevent
libffi
libiconv
libkxld
libmd
Libnotify
libpcap
Librpcsvc
libutil
man
ncurses
patch_cmds
pb_makefiles
pcre
system_config
SystemStubs
TargetConfig
TargetConfig_headers
texi2html
texinfo
UserNotification
uucp
xar
xelf

All are built as ppc+i386+x86_64.

A number of projects fail, and unfortunately it is not immediately clear, whether dependencies are needed, or headers should be installed first, or just code is broken and should be patched.

In any case, the approach seems reasonably workable; definitely it would take me longer to build all these manually (whether directly or via custom portfiles). But if all these were implemented via MacPorts, life would be easier, since MacPorts handles dependencies correctly (as long as those are specified), while Darwinbuild seems to expect you gonna guess the right order, and you are on your own. Compare how much easier it is to build `libdispatch` via my portfile. (But no, I am not gonna rewrite everything into portfiles, it is a lot of work.)

Yeah, building them all manually is a pain in the ass particularly with little indications of what order things should be built. It’s unfortunate that darwinbuild doesn’t automatically resolve dependencies so there’s still some ‘chicken and egg’ but certainly this will prove very useful. Great work @barracuda156.

 

[barracuda156]

Does anyone have tarballs (sources) of `libauto-141.2` and `SQLite-74.11`? Both are gone, apparently.

 

[Jazzzny]

https://web.archive.org/web/20111229172738if_/http://opensource.apple.com/tarballs/libauto/libauto-141.2.tar.gz

https://web.archive.org/web/20111229182153if_/http://opensource.apple.com/tarballs/SQLite/SQLite-74.11.tar.gz

 

[ADunsmuir]

Searching http://opensource.apple.com/source/ works.
Al

Source Browser

Source Browser

 

[barracuda156]

Does anyone know a way to install headers produced by `darwinbuild -nochroot -headers ${project}` into buildroot? Documentation lies (`bin/installheaders` is a non-existent binary). Those are apparently needed to build projects which are failing now.

P. S. Darwinbuild copies the following plug-in from Xcode:

~/10K540/Platform/Developer/Library/Xcode/Plug-ins/MacOSXPlatformPlugin.xcodeplugin/Contents/MacOS/MacOSXPlatformPlugin

Expectedly, in Xcode 3.2.6 it is Intel-only. Care should be taken to ensure we get a binary with a ppc slice here.

 

[ChrisCharman]

Just installed the prebuilt darwinbuild package from your site @barracuda and testing it out i’m finding a number of projects that should build, as i built them manually, don’t via darwinbuild due to universal binary complications as well as missing headers etc. I recommend changing the default build settings to ppc & i386 or better just ppc to avoid 32/64 bit problems as well as endian issues. As far as headers go, built projects or at minimum headers in the -nochroot setup may need to be actually installed to the main system to enable the building of further projects as they would be when building directly from source manually. I don’t know a quick and easy way to do this from within DarwinBuild at the moment so i’m assuming manually copying the required files over from the build directory is a temporary workaround. I recommend having a seperate partition used for building with internal system modifications as some of them can cause quirks and instability but nonetheless required to build system components. A number of projects do build though without issues so this is definitely going to be a helpful tool to have available again.

 

[barracuda156]

Just installed the prebuilt darwinbuild package from your site @barracuda and testing it out i’m finding a number of projects that should build, as i built them manually, don’t via darwinbuild due to universal binary complications as well as missing headers etc. I recommend changing the default build settings to ppc & i386 or better just ppc to avoid 32/64 bit problems as well as endian issues. As far as headers go, built projects or at minimum headers in the -nochroot setup may need to be actually installed to the main system to enable the building of further projects as they would be when building directly from source manually. I don’t know a quick and easy way to do this from within DarwinBuild at the moment so i’m assuming manually copying the required files over from the build directory is a temporary workaround. I recommend having a seperate partition used for building with internal system modifications as some of them can cause quirks and instability but nonetheless required to build system components. A number of projects do build though without issues so this is definitely going to be a helpful tool to have available again.

Thank you for trying!

There is one (new) patch missing also there (I did not rebuild the thing or update the port yet, but macos-powerpc/darwinbuild has it). You could just edit the script without rebuilding: https://github.com/macos-powerpc/darwinbuild/commit/5a6eb0f24887b9ea9e6050f390cf74ca7f7864cf (apply to /bin/darwinbuild in that case). This will fix some packages which use alias targets. There are two other cases in that chunk, for now I only changed what was proven to be required.

Darwinup should, from what it seems, be able to handle installs and updated into the system, but by default it does odd thing, installing stuff into /${project}-root/usr/ instead of just /usr/. Their notes are confusing for me, but perhaps it should be configurable, or in the worst case the source can be patched.

 

[barracuda156]

With headers, upstream suggested the following: https://github.com/macosforge/darwinbuild/issues/146#issuecomment-2560545342

Did not have time to try now, need some sleep, but will return to that.

 

[barracuda156]

P. S. Darwinbuild copies the following plug-in from Xcode:

~/10K540/Platform/Developer/Library/Xcode/Plug-ins/MacOSXPlatformPlugin.xcodeplugin/Contents/MacOS/MacOSXPlatformPlugin

Expectedly, in Xcode 3.2.6 it is Intel-only. Care should be taken to ensure we get a binary with a ppc slice here.

Looks like this plugin does not exist in earlier versions of Xcode (at least those which are known to be more or less ppc-compatible). Does anyone know how to disable it? It is very much likely non-essential, but it creates troubles if Xcode invokes it.

P. S. With other Xcode plugin we may be out of luck getting newer versions than we already have. I think that was why I eventually gave up on 10a222 Xcode on 10a190.

Sergey-Fedorovs-Mac:~ svacchanda\$ file /Volumes/Mercury/Xcode/10a314/Xcode\ Folder/DevToolsHIDDEN\ Folder/DeveloperTools\ Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin 
/Volumes/Mercury/Xcode/10a314/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin: Mach-O universal binary with 2 architectures
/Volumes/Mercury/Xcode/10a314/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture x86_64):    Mach-O 64-bit bundle x86_64
/Volumes/Mercury/Xcode/10a314/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture i386):    Mach-O bundle i386
Sergey-Fedorovs-Mac:~ svacchanda\$ file /Volumes/Mercury/Xcode/10a286/Xcode\ Folder/DevToolsHIDDEN\ Folder/DeveloperTools\ Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin 
/Volumes/Mercury/Xcode/10a286/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin: Mach-O universal binary with 2 architectures
/Volumes/Mercury/Xcode/10a286/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture x86_64):    Mach-O 64-bit bundle x86_64
/Volumes/Mercury/Xcode/10a286/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture i386):    Mach-O bundle i386
Sergey-Fedorovs-Mac:~ svacchanda\$ file /Volumes/Mercury/Xcode/10a261/Xcode\ Folder/DevToolsHIDDEN\ Folder/DeveloperTools\ Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin 
/Volumes/Mercury/Xcode/10a261/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin: Mach-O universal binary with 2 architectures
/Volumes/Mercury/Xcode/10a261/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture x86_64):    Mach-O 64-bit bundle x86_64
/Volumes/Mercury/Xcode/10a261/Xcode Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture i386):    Mach-O bundle i386
Sergey-Fedorovs-Mac:~ svacchanda\$ file /Volumes/Mercury/Xcode/10a222/XcodeTools\ Folder/DevToolsHIDDEN\ Folder/DeveloperTools\ Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin 
/Volumes/Mercury/Xcode/10a222/XcodeTools Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin: Mach-O universal binary with 2 architectures
/Volumes/Mercury/Xcode/10a222/XcodeTools Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture x86_64):    Mach-O 64-bit bundle x86_64
/Volumes/Mercury/Xcode/10a222/XcodeTools Folder/DevToolsHIDDEN Folder/DeveloperTools Folder/Library/Xcode/Plug-ins/XcodePerforcePlugin.xcplugin/Contents/MacOS/XcodePerforcePlugin (for architecture i386):    Mach-O bundle i386

It could be, in principle, that something accidentally gets ppc slice back after losing it, but perhaps chances are tiny. For Unix tools, a number of those retain ppc slices in 10a222, 10a261 and likely later Xcode versions, but those are better to rebuild from sources anyway.

Does someone remember a way to check everything that has a ppc slice with a script to be run over a contents of a directory?

 

[barracuda156]

Some observations on Darwinbuild natively on PowerPC

1. It works, provided that Xcode tools binaries are replaced with ppc-supporting versions. Some of those binaries are in unexpected locations:

make: execvp: javaconfig: Bad CPU type in executable
== Making installhdrs for ppc in common ==
/bin/sh: /Developer/Makefiles/pb_makefiles/dotdotify: Bad CPU type in executable
/bin/sh: /Developer/Makefiles/pb_makefiles/dotdotify: Bad CPU type in executable
/bin/sh: /Developer/Makefiles/pb_makefiles/dotdotify: Bad CPU type in executable
/bin/sh: /Developer/Makefiles/pb_makefiles/dotdotify: Bad CPU type in executable
/bin/sh: /Developer/Makefiles/pb_makefiles/dotdotify: Bad CPU type in executable
make[1]: execvp: javaconfig: Bad CPU type in executable
== Making NetInfo for ppc ==
Installing header files...
/bin/rm -rf /System/Library/PrivateFrameworks/NetInfo.framework/PrivateHeaders
/bin/mkdir -p /System/Library/PrivateFrameworks/NetInfo.framework/
/bin/ln -s Versions/Current/PrivateHeaders /System/Library/PrivateFrameworks/NetInfo.framework/PrivateHeaders
/bin/rm -rf /System/Library/PrivateFrameworks/NetInfo.framework/Headers
/bin/mkdir -p /System/Library/PrivateFrameworks/NetInfo.framework/
/bin/ln -s Versions/Current/Headers /System/Library/PrivateFrameworks/NetInfo.framework/Headers
/bin/mkdir -p /System/Library/PrivateFrameworks/NetInfo.framework/Versions/A/Headers
sh mk_version > /Users/svacchanda/10K540/BuildRoot/private/var/tmp/netinfo/netinfo-382.sym/netinfo.build/derived_src/common/project_version.h
make[1]: /Developer/Makefiles/pb_makefiles/fastcp: Bad CPU type in executable
make[1]: *** [install-public-headers] Error 1
make: *** [installhdrs@common] Error 2
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 BUILD TIME: 0h 0m 0s
EXIT STATUS: 2

Why on earth an executable will live in Makefiles folder?

2. Some projects have wrong archs hardcoded:

=== INSTALL HEADERS FOR NATIVE TARGET amt OF PROJECT OpenBSM WITH THE DEFAULT CONFIGURATION (Release) NOT USING PER-CONFIGURATION BUILD DIRECTORIES ===
Check dependencies
[BEROR]No architectures to compile for (ARCHS=ppc, VALID_ARCHS=armv6 i386 x86_64).

This will need to be patched.

3. Some Darwinbuild's own patches fail to apply and Darwinbuild does not err out on that (!):

*** Applying Patch IOKitUser-502.nohidevent.patch ...
patching file ./IOKitUser.xcodeproj/project.pbxproj
Hunk #1 FAILED at 349.
Hunk #2 succeeded at 2079 (offset 40 lines).
Hunk #3 FAILED at 2493.
2 out of 3 hunks FAILED -- saving rejects to file ./IOKitUser.xcodeproj/project.pbxproj.rej

This is just ridiculous. Thankfully not many projects have corresponding patches, but this should be monitored.

I have switched downloadable plists to build just for ppc for now.

P. S. A bit on a side note, perhaps it is sensible to nuke /usr/bin/clang and /Developer/usr/bin/clang; original binaries are Intel-only, and even if rebuilt from sources, clangs are known to produce bad code and also generate stupid errors even when their code seems to be functional. There is no benefit to having these, and unlike Xcode of 10a190, Xcode 3.2.6 tends to pick these time to time.

 

[ChrisCharman]

MERRY CHRISTMAS TO EVERYONE!

 

[barracuda156]

Weee, I got a bug! LLVM on 10.6.8 is broken. Interestingly, I get identical errors from trying to run the same LLVM from 10a190 volume (on 10.6.8), so it could be not the build as such is broken but something which it links to.
It does not link to many things. Possibly gcc10-bootstrap is broken, and if so, then perhaps it still needs some patching (I dropped the patch which I used on 10a190).

I will try to figure out what goes wrong here and update on that.

(gdb) run
Starting program: /opt/local/libexec/llvm-7.1.1/bin/llvm-nm 
Reading symbols for shared libraries .++++......... done
llvm-nm(83827) malloc: *** error for object 0x3773690: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal EXC_BAD_INSTRUCTION, Illegal instruction/operand.
0x040245f8 in llvm::windows_manifest::WindowsManifestError::ID ()
(gdb) bt
#0  0x040245f8 in llvm::windows_manifest::WindowsManifestError::ID ()
#1  0x0344f6b4 in _GLOBAL__sub_I_CommandLine.cpp ()
#2  0x8fe107a4 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#3  0x8fe107a4 in __dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE ()
#4  0x8fe0e97c in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#5  0x8fe0e8f4 in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#6  0x8fe0ea58 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#7  0x8fe02918 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#8  0x8fe07a8c in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#9  0x8fe0174c in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#10 0x8fe01064 in __dyld__dyld_start ()

On 10a190 this worked normally, I used this LLVM version with ld and cctools for months with zero issues.

It also might be that it needs CXX ABI flag on 10.6.8, but did not need it on 10a190 (I think the build does not pass it, despite using C++11). Given they are supposed to link somewhat differently to system libs, it is conceivable.
And well, I rather rebuild LLVM with an extra flag than the whole of GCC LOL.
(It is quite possible that I did not build llvm-powerpc on Rosetta, which means it has never been tested on 10.6.8 until now.)

 

[ChrisCharman]

@barracuda156 i forgot to mention that prebuilt darwinbuild package links to version of tcl in /opt so if anybody downloads the darwinbuild they will also need to download tcl prebuilt package if not installing directly from macports.

 

[barracuda156]

@barracuda156 i forgot to mention that prebuilt darwinbuild package links to version of tcl in /opt so if anybody downloads the darwinbuild they will also need to download tcl prebuilt package if not installing directly from macports.

Yes, that is a declared dependency in the portfile. Binaries are public and can be used in any desired manner, but the only recommended way to install (unless explicitly stated otherwise) is via ports. Otherwise a user is on their own.

(utdns is fine to install directly and in a random location, since it does not use any MacPorts stuff.)

 

[barracuda156]

LLVM 7.1.1 fixed for 10.6.8. One line fix, 2 hrs wasted.

Sergey-Fedorovs-Mac:~ svacchanda\$ /opt/local/libexec/llvm-7.1.1/bin/llvm-config
usage: llvm-config <OPTION>... [<COMPONENT>...]

Get various configuration information needed to compile programs which use
LLVM.  Typically called from 'configure' scripts.  Examples:
  llvm-config --cxxflags
  llvm-config --ldflags
  llvm-config --libs engine bcreader scalaropts

Options:
  --version         Print LLVM version.
  --prefix          Print the installation prefix.
  --src-root        Print the source root LLVM was built from.
  --obj-root        Print the object root used to build LLVM.
  --bindir          Directory containing LLVM executables.
  --includedir      Directory containing LLVM headers.
  --libdir          Directory containing LLVM libraries.
  --cmakedir        Directory containing LLVM cmake modules.
  --cppflags        C preprocessor flags for files that include LLVM headers.
  --cflags          C compiler flags for files that include LLVM headers.
  --cxxflags        C++ compiler flags for files that include LLVM headers.
  --ldflags         Print Linker flags.
  --system-libs     System Libraries needed to link against LLVM components.
  --libs            Libraries needed to link against LLVM components.
  --libnames        Bare library names for in-tree builds.
  --libfiles        Fully qualified library filenames for makefile depends.
  --components      List of all possible components.
  --targets-built   List of all targets currently built.
  --host-target     Target triple used to configure LLVM.
  --build-mode      Print build mode of LLVM tree (e.g. Debug or Release).
  --assertion-mode  Print assertion mode of LLVM tree (ON or OFF).
  --build-system    Print the build system used to build LLVM (always cmake).
  --has-rtti        Print whether or not LLVM was built with rtti (YES or NO).
  --has-global-isel Print whether or not LLVM was built with global-isel support (ON or OFF).
  --shared-mode     Print how the provided components can be collectively linked (`shared` or `static`).
  --link-shared     Link the components as shared libraries.
  --link-static     Link the component libraries statically.
  --ignore-libllvm  Ignore libLLVM and link component libraries instead.
Typical components:
  all               All LLVM libraries (default).
  engine            Either a native JIT or a bitcode interpreter.

Both cctools and ld64 link to llvm-powerpc fine now.

 

[ChrisCharman]

@barracuda156 possibly this will be useful but away from machines to test over xmas.

This command is a shell pipeline that performs the following steps:


1. find / -perm -u+x ! -type d -exec file {} \;


• Searches the entire filesystem (/) for files:


• With the -perm -u+x flag, it looks for files that are executable by the file owner.


• Excludes directories (! -type d).


• Runs the file command on each found file to determine its type, format, or architecture.


2. | grep -v 'for arch'


• Filters out lines from the file output that contain the string for arch. This step removes results referring to files that specify architectures explicitly.


3. | grep ppc


• Retains only lines mentioning “ppc,” which suggests PowerPC architecture compatibility.


4. | cut -d: -f1


• Extracts the file path by splitting the output on the : character and selecting the first field (the file path).





Summary





This command finds all executable (non-directory) files on the system, checks their file type, filters for those compatible with PowerPC architecture, and outputs their file paths. It likely can be used to identify binaries that can run on a PowerPC system.

 

[barracuda156]

A quick update: I got a lot of stuff building, no issues so far (besides the one mentioned above and already fixed), and importantly Qt4 builds for 10.6 target and with Cocoa support. This never worked on 10a190 and, AFAIK, did not work on Leopard for ppc (i.e. Cocoa). No patches were needed.
I have built QMPlay2 with the new Qt4 on 10.6.8, and crash on exiting the app is gone. GUI works, video works, YT playback works. Apparently no regressions, but at least some visible improvements.

This is yet to be verified on the generic image of 10.6.8; I am using Nvidia one on the Quad.

@educovas So far everything works great on 10.6.8 for development. (We still need to sort out Xcode CLI tools, of course, I just made some ad hoc replacements using my rebuilds with darwinbuild, AOS binaries shared here and components borrowed from 10a222 and 10a190.)

 

[barracuda156]

I got Xorg-server working now. So all end-user apps are supposed to work then (whatever worked on 10a190, at least).
I need to see if some stuff got fixed as a side-effect or became fixable.

P. S. Just as a reminder: Apple X11 must be removed, as in 10a190, and GTK4 apps need `GSK_RENDERER=cairo` in the environment (GTK2/GTK3 ones do not care, the bug is specific to GTK4).

 

[barracuda156]

@ChrisCharman @educovas There are no sources for `ibtool`?

We may have problems with apps which use Xcode do build native GUI. I borrowed `ibtool` from 10a222, and looks like it does not work with Xcode 3.2.6. Trying to build GitX, I get unrecognized selector sent to class exception in the log, and while the build succeeds, the app cannot launch. At the same time it builds fine in 10a190, and I also can use that app from 10a190 on 10.6.8.
This is not a big deal, since there are not many such apps, and it should be possible to either cross-compile from 10.6.8 x86 or use versions built on 10a190.

I do not know yet whether this is a general issue or something specific to GitX (or maybe `ibtool` from 10a222).

 

[ChrisCharman]

Can we not replace interface builder with an earlier powerpc version? Most of the apps outside of Xcode itself in 3.2.6 are intel and will need to be replaced.