Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
PPCPorts: the only ports you ever need on a PowerPC
- Thread starter barracuda156
- Start date
- Sort by reaction score
Thanks. So far it seems that only G4 builds are affected, though it could be a coincidence.
Thank you for posting the log, this is the same error myself and others have reported on G4s. Almost certainly this is a G4 exclusive bug.
Running
sudo ln -s /opt/local/var/macports/build/libgcc16-4cc3974b/work/gcc-16.1.0/libgcc/config/no-unwind.h /opt/local/var/macports/build/libgcc16-4cc3974b/work/gcc-16.1.0/libgcc/md-unwind-def.h
sudo port -v install gcc16
Should allow the build to continue. If it fails again with the same error, the same solution will likely work.
But this really should be fixed properly since it appears to affect all G4s running OS X (10.4-10.6).
Once someone can reproduce it without MacPorts / PPCPorts on 10.5 (this is the best choice for debugging with upstream), it can be fixed properly.
Andrew-R
macrumors 6502
It took me 10+22 hours for libgcc/gcc16 to compile on DC 2.0 Mac with 4Gb ram and original (I assume) mechanical sata 160 Gb hdd - but its finally compiled on Leopard, ppc32. No errors from gcc16 install itself with ports deactivated before making pkg out of port base, and then letting 'port install gcc16' activate them as needed, and finally now running 'port activate installed' so hopefully my PPCports install will be back.
Get myself logged out of machine once because while openssh was working as started even with deactivated ports, after power outage of course it was not there anymore, but vnc acces was still working, so I restarted libgcc16 build from there. Yeah, machine in just another room, I can walk there, but lesson to be remembered.
Get myself logged out of machine once because while openssh was working as started even with deactivated ports, after power outage of course it was not there anymore, but vnc acces was still working, so I restarted libgcc16 build from there. Yeah, machine in just another room, I can walk there, but lesson to be remembered.
Do you have gsed installed and active? It seems to be looking for that. And it doesn't hurt to have gsed installed regardless. May as well run
sudo port -v install gsed
It may be best to wait for @barracuda156 to give advice before resuming the build of gcc16 though.
It is generally not a good idea both to have unneeded ports active when building something important and randomly deactivating some ports in the middle of the build.
The log has:
Code:
:info:configure checking build system type... powerpc-apple-darwin10
:info:configure checking host system type... powerpc-apple-darwin10
:info:configure checking target system type... powerpc-apple-darwin10
:info:configure checking for a BSD-compatible install... /usr/bin/install -c
:info:configure checking whether ln works... yes
:info:configure checking whether ln -s works... yes
:info:configure checking for a sed that does not truncate output... /opt/local/bin/gsed
Code:
:info:build checking for ld used by /opt/local/var/macports/build/libgcc16-4cc3974b/work/build/./gcc/xgcc -B/opt/local/var/macports/build/libgcc16-4cc3974b/work/build/./gcc/ -B/opt/local/powerpc-apple-darwin10/bin/ -B/opt/local/powerpc-apple-darwin10/lib/ -isystem /opt/local/powerpc-apple-darwin10/include -isystem /opt/local/powerpc-apple-darwin10/sys-include -fno-checking... /opt/local/var/macports/build/libgcc16-4cc3974b/work/gcc-16.1.0/libatomic/configure: line 5320: /opt/local/bin/gsed: No such file or directory
:info:build /opt/local/var/macports/build/libgcc16-4cc3974b/work/build/./gcc/collect-ldSo apparently you started the build with gsed available, gcc was configured that way, then build was interrupted a few times, and at some point gsed port was deactivated. gcc cannot know something changed in the environment, unless configure is rerun. So it tries to use the executable which is no more.
I do not think gsed is needed to build gcc, but if you already had it, just activate it back. It is just a supporting build tool. Does not matter which version is used as long as it is the same during the build.
Well, it does hurt for debugging. Not gsed as such (it should work fine), but usage of unpredictable and undisclosed dependencies.
Building at least on 10.6.8 (native ppc, NOT rosetta) should really just work without any manual manipulations. While it can use some alternative tools, it will probably make life easier to avoid experimenting. I always run builds of fundamental ports (in fact of most compiled ports) starting from deactivating everything, so I am reasonably sure that anyone can build the same, following the same procedure. Conversely, following a different procedure may have unexpected results.
P. S. I do not suggest to clean and run a fresh build right now, since hopefully activating gsed back will do the trick, but generally I suggest to bear with port deactivation prior to building something huge: it needs an extra couple of minutes, but may save hours.
saxfun
macrumors regular
Activating gsed did Not do the Trick.
Bildung failed again. 10.6.8 A5 Image on G4, A1138.
Giving up. Maybe I do uninstall whole macports and begin from scratch in the Future.
Or Maybe it is simply to hot to think clearly, 39 Degrees Celsius and Bad Air in Western Germany.
Bildung failed again. 10.6.8 A5 Image on G4, A1138.
Giving up. Maybe I do uninstall whole macports and begin from scratch in the Future.
Or Maybe it is simply to hot to think clearly, 39 Degrees Celsius and Bad Air in Western Germany.
Would you just install the pre-built package?
This will install right-away:
Code:
sudo port -v -b install libgcc16 +G5 gcc16 +G5+G5 is optimized for G5 but gonna work on G4 too.
My rosetta build just finished, so there will be a generic libgcc16 too now (not gcc16 at the moment, it takes forever to build for me either).
Last edited:
Pre-built (for 10.6.8 ppc):
G5-optimized versions are built natively on G5, generic one built on Rosetta.
G5-optimized versions are built natively on G5, generic one built on Rosetta.
In fact you may not need the compiler as such at all, at least not urgently, since for pre-built packages only the runtime is needed (i.e. libgcc).
Andrew-R
macrumors 6502
A bit offtop for PPCPorts but while looking for alac_at/aac_at ffmpeg encoders bugs on ppc leopard I installed Intel Leopard on hvf accelerated qemu 9.0.3 on Sierra host.
Now I have two Intel Leopards but i386 Leo on pure Macports fails to build gettext for me, so much of ports depending on it alsofails.
Now I have two Intel Leopards but i386 Leo on pure Macports fails to build gettext for me, so much of ports depending on it alsofails.
A bit offtop for PPCPorts but while looking for alac_at/aac_at ffmpeg encoders bugs on ppc leopard I installed Intel Leopard on hvf accelerated qemu 9.0.3 on Sierra host.
Now I have two Intel Leopards but i386 Leo on pure Macports fails to build gettext for me, so much of ports depending on it alsofails.
i386 is an utter pain to deal with. Which on ppc most of ports just lack simd codepaths, on i386 some will have, but broken, because everyone just assumes avx and friends are supported, but they aren’t by cctools of 10.5/10.6.
I had a brief period of maintaining i386 system, ppc was a piece of cake in comparison. (Since then my MacMini i386 stopped launching.)
Andrew-R
macrumors 6502
@barracuda156
it seems that on x86_64 Snow Leo ffmpeg 6.1.6 self-compiled with --enable-audiotoolbox and gcc 13.2 from Macports produces normal-sounding aac file but asserts at encoding alac_at
There was little define change by me in libavcodec/audiotoolboxenc.c - one of aac profiles (ELD) was not on my 10.6.8 system so I moved min version to 10.7
On Leo ppc32 all ffmpegs down to ffmpeg4 produce noise on aac_at codec, and broken file on alac_at (muxing into m4a)
Not sure if I can test at i386 Leo due to macports being a bit broken there ATM
it seems that on x86_64 Snow Leo ffmpeg 6.1.6 self-compiled with --enable-audiotoolbox and gcc 13.2 from Macports produces normal-sounding aac file but asserts at encoding alac_at
There was little define change by me in libavcodec/audiotoolboxenc.c - one of aac profiles (ELD) was not on my 10.6.8 system so I moved min version to 10.7
On Leo ppc32 all ffmpegs down to ffmpeg4 produce noise on aac_at codec, and broken file on alac_at (muxing into m4a)
Not sure if I can test at i386 Leo due to macports being a bit broken there ATM
Andrew-R
macrumors 6502
Interestingly git history for this file shows it was modified to support building on 10.5:
but not sure if it was runtime-tested on this version or not
but not sure if it was runtime-tested on this version or not
Matias_
macrumors regular
Oh huh, I ran into this problem (specifically for ffmpeg versions 4 & 5) and submitted a patch for it: https://github.com/macos-powerpc/powerpc-ports/pull/114/changes
I didn't know that this was already resolved upstream. Perhaps my patch can be dropped in favor of this, it looks cleaner.
CC @barracuda156
Andrew-R
macrumors 6502
I also tried audiotoolbox decoding, it seems to be byteswapped on ppc:
ffmpeg8 -c:a mp2_at -i 1.mp2 -f s16be 1.pcm
mv 1.pcm 1.raw
sox -r 48k -e signed -c 2 -b 16 1.raw -x 1-sox.wav
makes correct sound. Note "x" flag for SoX
may be audiotoolbox need isbigendian flag set on be hosts for its output buffers?
ffmpeg8 -c:a mp2_at -i 1.mp2 -f s16be 1.pcm
mv 1.pcm 1.raw
sox -r 48k -e signed -c 2 -b 16 1.raw -x 1-sox.wav
makes correct sound. Note "x" flag for SoX
may be audiotoolbox need isbigendian flag set on be hosts for its output buffers?
Andrew-R
macrumors 6502
@barracuda156 @Matias_
can you check attached patches?
they work for me (mp2_at dec stereo, acc_at enc stereo) on 10.5.8 ppc32 leopard, gcc16, ffmpeg 6.1.6
can you check attached patches?
they work for me (mp2_at dec stereo, acc_at enc stereo) on 10.5.8 ppc32 leopard, gcc16, ffmpeg 6.1.6
Look good to me. (I did not verify types used for casting, but as long as that compiles and works, they should be correct.)