babl @0.1.14 falls back to clang-3.4 which is not functional on PPC platforms

[udbraumann]

$ sudo port info --pretty --depends babl
Build Dependencies:   clang-3.4

As you may know, clang-3.4 is not functional on PPC platforms. So I wonder if instead gcc5 could be generally used, as

$ sudo port -s install babl configure.compiler=macports-gcc-5

successfully works even on PPC?

[dbevans (David B. Evans)]

It's best to stick with clang as much as possible for compatibility with other ports so the best solution would be to resolve the clang 3.4 issue or update the the compiler.fallback list in base to pick a better choice for your platform. Of course, you are free to make site specific changes to your ports to work around issues like these if you know what to change.

If you manually build babl as you have indicated can you build a gimp2 that works? Or are you using gcc5 for everything? What version of OS X and Xcode are you using?

Copying a few other developers that may have a more informed opinion on this subject.

[dbevans (David B. Evans)]

To clarify, I'm thinking that, if there's a better compiler choice than clang-3.4 for powerpc platforms, the fallback list should be modified to reflect that choice rather than override it in each port.

[udbraumann]

Thanks for paying attention to my suggestion. Since gcc5 is available on macports, the situation for PPC has improved!

Well, gimp2 presently cannot be built on PPC (10.5.8, Xcode 3.1.4) since unfortunately webkit-gtk-2.0 does not build (I forgot why). To be honest, I also do not know why babl was installed on my system which I managed to upgrade recently (see above), it presently has no dependents.

Anyway, there are a few ports requiring clang-3.* which in fact also can be built using gcc5. clang-3.4 builds on PPC, but it is not functional! I leave it to you as expert(s) what mechanism is best to include gcc5 as replacement for PPC. compiler.fallback is only effective if a certain required compiler, say clang-3.* is blacklisted for a certain platform?

I am sure that not all ports requiring clang-3.* (and llvm-3.*) can be built using gcc5 on PPC, but e.g. py27-gobject3 or gnome-keyring and babl and others can.

[dbevans (David B. Evans)]

Replying to braumann@…:

Thanks for paying attention to my suggestion. Since gcc5 is available on macports, the situation for PPC has improved!

Well, gimp2 presently cannot be built on PPC (10.5.8, Xcode 3.1.4) since unfortunately webkit-gtk-2.0 does not build (I forgot why).

webkit-gtk is only required for the gimp2 help browser so if you don't care about that you can disable it by building gimp2 -help_browser.

To be honest, I also do not know why babl was installed on my system which I managed to upgrade recently (see above), it presently has no dependents.

babl is a dependency of gegl and both are used to build gimp2. Otherwise you don't need it. That's why I asked.

Anyway, there are a few ports requiring clang-3.* which in fact also can be built using gcc5. clang-3.4 builds on PPC, but it is not functional! I leave it to you as expert(s) what mechanism is best to include gcc5 as replacement for PPC. compiler.fallback is only effective if a certain required compiler, say clang-3.* is blacklisted for a certain platform?

I am sure that not all ports requiring clang-3.* (and llvm-3.*) can be built using gcc5 on PPC, but e.g. py27-gobject3 or gnome-keyring and babl and others can.

Yes, there are a number of other tickets open with similar reports involving a number of specific ports that don't build on PPC due to compiler issues. So the central issue is finding a compiler that can be built and work on PPC that will compile code written to more modern standards.

[jeremyhu (Jeremy Huddleston Sequoia)]

YMMV with clang and ppc. More recent versions are much better, but it is far from perfect.

I believe clang-3.4 should be usable for compiling C code for darwin/ppc.

This issue really requires someone with Leopard/ppc to provide a patch.

[jeremyhu (Jeremy Huddleston Sequoia)]

If you need something even newer than clang-3.4 on ppc, you'll first need to fix ​http://www.llvm.org/bugs/show_bug.cgi?id=22270

[udbraumann]

Replying to jeremyhu@…:

... I believe clang-3.4 should be usable for compiling C code for darwin/ppc. ...

I have made some tests.

I called this one-liner on my 10.5.8 PPC:

$ printf '#include<stdio.h> \n int main(void) {fprintf(stderr,"Hello, world\\n");}' | clang-mp-3.4 -arch ppc -xc -o out.exe -

unfortunately leads to

clang(65051) malloc: *** error for object 0xa082a708: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
...
MORE THAN 100 REPETITIONS OF SIMILAR ERROR MESSAGES FOLLOW
...
ld: absolute address to symbol ___stderrp in a different linkage unit not supported in _main from /var/folders/fH/fHv2DgyLHvS8wcc5wmXwHU+++TM/-Tmp-/--d552c5.o
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)

However, calling

$ printf '#include<stdio.h> \n int main(void) {fprintf(stderr,"Hello, world\\n");}' | clang-mp-3.4 -arch i386 -xc -o out.exe -

I get a less repetition of "Non-aligned pointer being freed" message:

clang(65075) malloc: *** error for object 0xa082a708: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
...
ONLY ABOUT 20 REPETITIONS OF THIS ERROR FOLLOW
...

Anyway, this time with the i386 architecture switch an executable out.exe is being produced using mp-clang-3.4 on 10.5.8 32bit PPC, which can be transferred to a 10.6.8 x86_64 platform, where "Hello, world" is being printed when out.exe is executed.

Looking from the other side, calling

$ printf '#include<stdio.h> \n int main(void) {fprintf(stderr,"Hello, world\\n");}' | clang-mp-3.4 -arch ppc -xc -o out.exe -

on a 10.6.8 x86_64 the following error is returned complaining about a missing assembler (no idea how to install it):

/usr/llvm-gcc-4.2/bin/../libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/as/ppc/as or /usr/bin/../local/libexec/as/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/as/x86_64/as for architecture x86_64
/usr/bin/../libexec/as/i386/as for architecture i386
/usr/bin/../libexec/as/arm/as for architecture arm
clang: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)

Anyway, this works on 10.6.8:

$ printf '#include<stdio.h> \n int main(void) {fprintf(stderr,"Hello, world\\n");}' | clang-mp-3.4 -arch i386 -xc -o out.exe -

and

$ printf '#include<stdio.h> \n int main(void) {fprintf(stderr,"Hello, world\\n");}' | clang-mp-3.4 -arch x86_64 -xc -o out.exe -

$ ./out.exe
Hello, world

[jeremyhu (Jeremy Huddleston Sequoia)]

Darn. That's unfortunate. On my x86_64 SnowLeopard MacMini, I'm able to compile simple C code for ppc and run it through rosetta:

~ $ cat hello.c
#include <stdio.h>

int main() {
    printf("Hello!\n");
    return 0;
}

~ $ clang-mp-3.4 -arch ppc hello.c -o hello.ppc

~ $ ./hello.ppc 
Hello!

---

Is the cctools port installed and active on your 10.6.8 box when you are seeing that error?

[udbraumann]

Is the cctools port installed and active on your 10.6.8 box when you are seeing that error?

Yes:

$ sudo port installed cctools
The following ports are currently installed:
  cctools @877.5_1+llvm34 (active)

I am afraid, that Xcode 4.2 providing llvm-gcc-4.2 somehow is interferring with cctools, so that the assembler for ppc is not being found.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ugg. The issue is that clang-3.4 falls back on /usr/bin/gcc for ppc. It was 3.5 that started doing it internally.

Try using llvm-3.5 or newer on your SL box. Make sure you have the +ld64_127 variant for ld64 installed or your linker won't support ppc.

[jeremyhu (Jeremy Huddleston Sequoia)]

3.5 has a bug with the linker command line, but 3.6 works here. More complex code won't compile due to the missing slice in libclang_rt. We should figure out why that isn't getting built.

~ $ clang-mp-3.6 -arch ppc -mmacosx-version-min=10.5 hello.c -o hello.ppc
ld: warning: ignoring file /opt/local/libexec/llvm-3.6/bin/../lib/clang/3.6.2/lib/darwin/libclang_rt.osx.a, missing required architecture ppc in file

~ $ ./hello.ppc 
Hello!

[udbraumann]

Try using llvm-3.5 or newer on your SL box. Make sure you have the +ld64_127 variant for ld64 installed or your linker won't support ppc.

Oh, I was not aware of variants of ld64. Thanks for this advice, and with the preset +ld64_136 the linker says

ld: unknown/unsupported architecture name for: -arch ppc

What is also decisive is the -mmacosx-version-min=10.5 for the compiler call, otherwise linking fails:

ld: symbol dyld_stub_binder not found (normally in libSystem.dylib).  Needed to perform lazy binding to function _exit for architecture ppc

I can confirm now that this call works on 10.6.8 using Rosetta (also for mp-clang-3.7 and mp-clang-3.8, btw.):

printf '#include<stdio.h> \n int main(void) {fprintf(stderr,"Hello, world\\n");}' | clang-mp-3.6 -arch ppc -mmacosx-version-min=10.5 -x c -o out.exe - && ./out.exe && rm -f out.exe

ld: warning: ignoring file /opt/local/libexec/llvm-3.6/bin/../lib/clang/3.6.2/lib/darwin/libclang_rt.osx.a, missing required architecture ppc in file
Hello, world

The warning concerning libclang_rt.osx.a providing nothing for ppc architecture might be another field of research.

So, maybe I should try again to build clang-3.6 on PPC? But if I remember right, building is blocked on PPC, and it requires clang-3.4 (which possibly can be replaced with gcc-5)...

In case it builds (I remember there was trouble, but forgot any details), do you think there is also something to modify for ld64 on PPC?

Or should I first try to take explicitely -mmacosx-version-min=10.5 even for clang-3.4 on 10.5.8 PPC?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jeremyhu@…:

ld: warning: ignoring file /opt/local/libexec/llvm-3.6/bin/../lib/clang/3.6.2/lib/darwin/libclang_rt.osx.a, missing required architecture ppc in file

If the ppc-compatible ld64 variant is active when clang-3.6 is built, libclang_rt.osx.a will have a ppc slice.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to braumann@…:

So, maybe I should try again to build clang-3.6 on PPC? But if I remember right, building is blocked on PPC, and it requires clang-3.4 (which possibly can be replaced with gcc-5)...

In case it builds (I remember there was trouble, but forgot any details), do you think there is also something to modify for ld64 on PPC?

On your Leopard/ppc box, you should have +ld64_127 as the default variant.

Or should I first try to take explicitely -mmacosx-version-min=10.5 even for clang-3.4 on 10.5.8 PPC?

You can explore whichever direction you think will work. I'd probably try to use gcc-5 to build clang-3.7 as a starting point. One of your biggest roadblocks will be ​http://www.llvm.org/bugs/show_bug.cgi?id=22270

Once the exceptions bug is fixed, there's not really telling what other issues you'll start to uncover, but as you get fixes, please send patches.

[udbraumann]

Replying to jeremyhu@…:

Replying to jeremyhu@…:

ld: warning: ignoring file /opt/local/libexec/llvm-3.6/bin/../lib/clang/3.6.2/lib/darwin/libclang_rt.osx.a, missing required architecture ppc in file

If the ppc-compatible ld64 variant is active when clang-3.6 is built, libclang_rt.osx.a will have a ppc slice.

Yes, that is true, and the same has worked for clang-3.7 (only clang-3.8 does not build on 10.6.8. at the moment, while but the binary installation works, of course without ppc architecture in libclang_rt.osx.a).

[jeremyhu (Jeremy Huddleston Sequoia)]

Please file a bug report for your llvm-3.8 build failure.

[udbraumann]

As #49866 is solved now, I can confirm that also clang-3.8 is able to generate ppc code which can be executed via Rosetta on 10.6.8:

$  clang-mp-3.8 -arch ppc -mmacosx-version-min=10.5 hello.c -o hello.ppc
$ ./hello.ppc
Hello!

Since I selected the +ld64_127 variant for ld64 the library libclang_rt.osx.a works for ppc without complaint. Of course this hello.ppc can also be executed on a physical 10.5.8 PPC.

[khepler]

Cc Me!

[mojca (Mojca Miklavec)]

Cc Me!

[ken-cunningham-webuse]

going to help take a stab at this. First the basics. On Leopard PPC, standard /opt/local install, no funny configurations, macports defaults.

have installed

$ port -v installed | grep clang
  clang-3.4 @3.4.2_11+analyzer (active) platform='darwin 9' archs='ppc'
  clang_select @2_0 (active) platform='darwin 9' archs='noarch'

port -v installed | grep llvm 
  cctools @886_6+llvm33 (active) platform='darwin 9' archs='ppc'
  ld64-127 @127.2_7+llvm33 (active) platform='darwin 9' archs='ppc'
  llvm-3.3 @3.3_10 (active) platform='darwin 9' archs='ppc'
  llvm-3.4 @3.4.2_11 (active) platform='darwin 9' archs='ppc'
  llvm_select @2_0 (active) platform='darwin 9' archs='noarch'

$ port select --list gcc
Available versions for gcc:
	gcc40
	gcc42 (active)
	llvm-gcc42
	none

$ls -la /opt/local/bin/gcc
lrwxr-xr-x  1 root  admin  16 Oct 22 18:33 /opt/local/bin/gcc -> /usr/bin/gcc-4.2

simple hello.c test

$ cat hello.c
#include <stdio.h>

int main() {
    printf("Hello!\n");
    return 0;
}

puts out

$ clang -v -arch ppc hello.c -o hello.ppc
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix
Selected GCC installation: 
 "/opt/local/libexec/llvm-3.4/bin/clang" -cc1 -triple powerpc-apple-darwin9.8.0 -S -disable-free -disable-llvm-verifier -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -target-linker-version 127.2 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -fno-dwarf2-cfi-asm -fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /users/shared/libunwind_test -ferror-limit 19 -fmessage-length 123 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/tmp/hello-15e6ee.s -x c hello.c
clang -cc1 version 3.4.2 based upon LLVM 3.4.2 default target powerpc-apple-darwin9.8.0
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/bin/gcc" -v -c -arch ppc -m32 -o /var/tmp/hello-155d32.o -x assembler /var/tmp/hello-15e6ee.s
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/as -arch ppc -o /var/tmp/hello-155d32.o /var/tmp/hello-15e6ee.s
 "/opt/local/bin/gcc" -v -arch ppc -m32 -o hello.ppc /var/tmp/hello-155d32.o
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/collect2 -dynamic -arch ppc -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o hello.ppc -lcrt1.10.5.o -L/usr/lib/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../.. /var/tmp/hello-155d32.o -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem

and works

$ ./hello.ppc
Hello!

So we have a working clang-3.4 that can compile c code. If I understand correctly what is going on here, clang is compiling c code to an assembly language file

 "/opt/local/libexec/llvm-3.4/bin/clang" -cc1 -triple powerpc-apple-darwin9.8.0 -S -disable-free -disable-llvm-verifier -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -target-linker-version 127.2 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -fno-dwarf2-cfi-asm -fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /users/shared/libunwind_test -ferror-limit 19 -fmessage-length 123 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/tmp/hello-15e6ee.s -x c hello.c

and then gcc-4.2 is taking it from there, and using gcc's assembler

/usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/as -arch ppc -o /var/tmp/hello-155d32.o /var/tmp/hello-15e6ee.s

and then gcc's linker

/usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/collect2 -dynamic -arch ppc -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o hello.ppc -lcrt1.10.5.o -L/usr/lib/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../.. /var/tmp/hello-155d32.o -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem

to give us a working binary

[ken-cunningham-webuse]

I should also mention that libunwind has been installed on this 10.5 PPC system

$ port -v installed libunwind
The following ports are currently installed:
  libunwind @3.9.0_0 (active) platform='darwin 9' archs='ppc'

Now we'll try the problem.

$ cat test_throw.cxx
#include <stdio.h>

int main(int argc, char **argv) {
    try {
        const char *message = "This is a test";
        throw message;
        return 0;
    } catch(const char* result) {
        printf("caught: %s\n", result);
        return 1;
    }
}

give us

$ clang++ -arch ppc -m32 test_throw.cxx -o test_throw.ppc
ld: absolute address to symbol typeinfo for char const*in a different linkage unit not supported in _main from /var/tmp/test_throw-ca2a9c.o
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)

or in more detail

$ clang++ -v -arch ppc -m32 test_throw.cxx -o test_throw.ppc
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix
Selected GCC installation: 
 "/opt/local/libexec/llvm-3.4/bin/clang" -cc1 -triple powerpc-apple-darwin9.8.0 -S -disable-free -disable-llvm-verifier -main-file-name test_throw.cxx -mrelocation-model static -mdisable-fp-elim -fmath-errno -target-linker-version 127.2 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -fdeprecated-macro -fno-dwarf2-cfi-asm -fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /users/shared/libunwind_test -ferror-limit 19 -fmessage-length 123 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/tmp/test_throw-ec05cb.s -x c++ test_throw.cxx
clang -cc1 version 3.4.2 based upon LLVM 3.4.2 default target powerpc-apple-darwin9.8.0
ignoring nonexistent directory "/usr/include/c++/4.2.1"
ignoring nonexistent directory "/usr/include/c++/4.2.1/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/include/c++/4.2.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.0.0/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/backward
 /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/bin/g++" -v -c -arch ppc -m32 -o /var/tmp/test_throw-bee4af.o -x assembler /var/tmp/test_throw-ec05cb.s
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/as -arch ppc -o /var/tmp/test_throw-bee4af.o /var/tmp/test_throw-ec05cb.s
 "/opt/local/bin/g++" -v -arch ppc -m32 -o test_throw.ppc /var/tmp/test_throw-bee4af.o
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/collect2 -dynamic -arch ppc -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o test_throw.ppc -lcrt1.10.5.o -L/usr/lib/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../.. /var/tmp/test_throw-bee4af.o -lstdc++ -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem
ld: absolute address to symbol typeinfo for char const*in a different linkage unit not supported in _main from /var/tmp/test_throw-bee4af.o
collect2: ld returned 1 exit status
clang: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation)

I don't really understand why it says 'char const* in a different linkage unit', but it seems to be missing a standard library of some kind. but 'lstdc++' is in the link libraries above ... hmmm.

trying g++

$ g++ -v -arch ppc -m32 test_throw.cxx -o test_throw.ppc
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/cc1plus -quiet -v -D__DYNAMIC__ test_throw.cxx -fPIC -quiet -dumpbase test_throw.cxx -mmacosx-version-min=10.5.8 -m32 -auxbase test_throw -version -D__private_extern__=extern -o /var/tmp//cctSwycN.s
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../../powerpc-apple-darwin9/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/powerpc-apple-darwin9
 /usr/include/c++/4.0.0/backward
 /usr/lib/gcc/powerpc-apple-darwin9/4.2.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
GNU C++ version 4.2.1 (Apple Inc. build 5577) (powerpc-apple-darwin9)
	compiled by GNU C version 4.2.1 (Apple Inc. build 5577).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a531a339ffc716e1aa139cbb61673b62
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/as -arch ppc -o /var/tmp//ccZuaFob.o /var/tmp//cctSwycN.s
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/collect2 -dynamic -arch ppc -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o test_throw.ppc -lcrt1.10.5.o -L/usr/lib/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../.. /var/tmp//ccZuaFob.o -lstdc++ -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem

works just perfectly, which hurts a bit

$ ./test_throw.ppc
caught: This is a test

So now if we can just get clang to compile it like that instead of g++, we'll be laughing.

[ken-cunningham-webuse]

well, it took a little messing around and trying various things, but this compile line finally worked:

$ cat test_throw.cxx
#include <cstdio>
#include <cstdlib>

int main(int argc, char **argv) {
    try {
        const char *message = "This is a test";
        throw message;
        return 0;
    } catch(const char* result) {
        printf("caught: %s\n", result);
        return 1;
    }
}

clang++ -arch ppc -I/usr/include/c++/4.0.0/powerpc-apple-darwin9 -fPIE -pie -stdlib=libstdc++ -m32 test_throw.cxx -o test_throw.ppc

which gave us

$ ./test_throw.ppc
caught: This is a test

and -to me- that looks like it's working. Here's the full build

$ clang++ -v -arch ppc -I/usr/include/c++/4.0.0/powerpc-apple-darwin9 -fPIE -pie -stdlib=libstdc++ -m32 test_throw.cxx -o test_throw.ppc
clang version 3.4.2 (tags/RELEASE_34/dot2-final)
Target: powerpc-apple-darwin9.8.0
Thread model: posix
Selected GCC installation: 
 "/opt/local/libexec/llvm-3.4/bin/clang" -cc1 -triple powerpc-apple-darwin9.8.0 -S -disable-free -disable-llvm-verifier -main-file-name test_throw.cxx -mrelocation-model pic -pic-level 2 -pie-level 2 -mdisable-fp-elim -fmath-errno -target-linker-version 127.2 -v -resource-dir /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2 -I /usr/include/c++/4.0.0/powerpc-apple-darwin9 -stdlib=libstdc++ -fdeprecated-macro -fno-dwarf2-cfi-asm -fno-dwarf-directory-asm -fno-autolink -fdebug-compilation-dir /users/shared/libunwind_test -ferror-limit 19 -fmessage-length 230 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-slp -o /var/tmp/test_throw-5b39d8.s -x c++ test_throw.cxx
clang -cc1 version 3.4.2 based upon LLVM 3.4.2 default target powerpc-apple-darwin9.8.0
ignoring nonexistent directory "/usr/include/c++/4.2.1"
ignoring nonexistent directory "/usr/include/c++/4.2.1/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/include/c++/4.2.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.0.0/powerpc-apple-darwin10/"
ignoring nonexistent directory "/usr/local/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.0.0/powerpc-apple-darwin9
 /usr/include/c++/4.0.0
 /usr/include/c++/4.0.0/backward
 /opt/local/libexec/llvm-3.4/bin/../lib/clang/3.4.2/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/bin/g++" -v -I /usr/include/c++/4.0.0/powerpc-apple-darwin9 -fPIE -pie -stdlib=libstdc++ -c -arch ppc -m32 -o /var/tmp/test_throw-4a3122.o -x assembler /var/tmp/test_throw-5b39d8.s
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/as -arch ppc -o /var/tmp/test_throw-4a3122.o /var/tmp/test_throw-5b39d8.s
 "/opt/local/bin/g++" -v -I /usr/include/c++/4.0.0/powerpc-apple-darwin9 -fPIE -pie -stdlib=libstdc++ -arch ppc -m32 -o test_throw.ppc /var/tmp/test_throw-4a3122.o
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure --disable-checking --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
 /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/collect2 -dynamic -arch ppc -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o test_throw.ppc -lcrt1.10.5.o -L/usr/lib/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../powerpc-apple-darwin9/4.2.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../.. /var/tmp/test_throw-4a3122.o -lstdc++ -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem

[ken-cunningham-webuse]

Now I will admit I'm a bit - uncertain. Is the libunwind bug on 10.5 Leopard (PPC) fixed now? Or have I tricked myself somehow?

Need help from the experts. -- K

[larryv (Lawrence Velázquez)]

You aren’t using libunwind. Note that your C++ library is libstdc++, not libc++.

[jeremyhu (Jeremy Huddleston Sequoia)]

clang-3.4 may compile some C code just fine, but it has some codegen issues and also has issues with floating point.

libunwind will compile just fine, but it will crash if your C++ code throws exceptions.

[ken-cunningham-webuse]

Thanks, Larry and Jeremy. Well - I was going to ask what the next step is. But perhaps that's not the right question.

[ken-cunningham-webuse]

keeping everyone in the loop - apologies if no-one is too interested. libcxx would not build far on ppc so rather than sort that out just now, I went back to 10.5 intel and built it there. testing libunwind (now 3.9.0) doesn't exactly segfault any longer, but does error out and abort. here's what I saw:

$ cat test_throw.cxx
#include <cstdio>
#include <cstdlib>

int main(int argc, char **argv) {
    try {
        const char *message = "This is a test";
        throw message;
        return 0;
    } catch(const char* result) {
        printf("caught: %s\n", result);
        return 1;
    }
}


$ clang++ -arch i386 -stdlib=libstdc++ test_throw.cxx -o test_throw.i386
$ ./test_throw.i386
caught: This is a test

$ clang++ -arch i386 -stdlib=libc++ test_throw.cxx -o test_throw.libcxx.i386
$ ./test_throw.libcxx.i386
libc++abi.dylib: terminating with uncaught exception of type char const*
Abort trap

[larryv (Lawrence Velázquez)]

Replying to ken-cunningham-webuse:

keeping everyone in the loop - apologies if no-one is too interested.

I wouldn’t say I’m not interested, just that this is very low on my to-do list right now. I encourage your continued experimenting.

[larryv (Lawrence Velázquez)]

Replying to ken-cunningham-webuse:

I was going to ask what the next step is. But perhaps that's not the right question.

I can’t help but think that the libunwind exception bug is a blocker here. That needs to be fixed.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yea, the libunwind is the blocker here. That's exactly what I said in the 'Leopard (ppc)' section on ​https://trac.macports.org/wiki/LibcxxOnOlderSystems ;)

I suggest you dive into ​http://www.llvm.org/bugs/show_bug.cgi?id=22270 for that.

[larryv (Lawrence Velázquez)]

Replying to jeremyhu:

That's exactly what I said in the 'Leopard (ppc)' section on the LibcxxOnOlderSystems wiki ;)

I knew that thought came from somewhere else! :P

[ken-cunningham-webuse]

I am digging in as my skills allow. Doesn't help that ddd won't build for me, gdb is a bugger to use, and I can't seem to get it into Xcode to debug. So from a tool point of view, it's a bit mucky. The same executable gives a proper throw-catch on SL with the same libunwind, libcxxabi, and libcxx code (all versioned at 3.9.0), and the same libgcc (10.6 version moved over to 10.5 as per the Leopard wiki).

So something about the way 10.5 is building it is the issue. pthreads, stack alignment..., stuff in the kernel..., differences in #include files... I wonder if I can diff libunwind from 10.5 and 10.6 and get a clue what might be different in these two files that way... or build libunwind for 10.5 on 10.6 and try using that binary...

At least I'm at the cliff edge. K

[jeremyhu (Jeremy Huddleston Sequoia)]

On Snow Leopard, we use the host libunwind, not the MacPorts one. That's why you're seeing it work on Snow Leopard.

[ken-cunningham-webuse]

OK. Learning about gdb, etc. here's what happens when trying to run the ./test_throw program on 10.5 leopard Intel compiled with clang-3.7, libcxx 3.9.0, libcxxabi 3.9.0, and libunwind 3.9.0

this certainly looks like a bug to my untrained eyes. malloc is trying to allocate a huge amount of memory. Probably because the thrown_size=0? I'll post the whole gdb log as an attachement -- K

__cxa_allocate_exception (thrown_size=0) at ../src/cxa_exception.cpp:159
159	_LIBCXXABI_FUNC_VIS void *__cxa_allocate_exception(size_t thrown_size) throw() {
(gdb) 
Current language:  auto; currently c++
__cxxabiv1::do_malloc (size=3221223824) at ../src/cxa_exception.cpp:164
164	    std::memset(exception_header, 0, actual_size);
(gdb) 
164	    std::memset(exception_header, 0, actual_size);
(gdb) 
111	    void *ptr = std::malloc(size);
(gdb) 
0x002408a2 in __cxxabiv1::do_malloc () at fallback_malloc.ipp:-1
Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x002408a4	Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x002408a7	Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x002408a8	Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x002408a9	Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x002408aa	Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x002408ab in __cxxabiv1::do_malloc () at fallback_malloc.ipp:-1
Line number -1 out of range; fallback_malloc.ipp has 188 lines.
(gdb) 
0x00001dd9 in main ()
(gdb) 
Single stepping until exit from function main, 
which has no line number information.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x45b0cd7f

[ken-cunningham-webuse]

gdb log of test_throw.cxx

[ken-cunningham-webuse]

I realize some debugging information was not available, so I force uninstalled and reinstalled the relevant ports, leaving the source available and hopefully with the proper debugging information in all of them. I'll upload the new log. I think libcxx might still have some optimization enabled.

[ken-cunningham-webuse]

I've continued to plug away at this. I've become convinced the error must be in this line

const uint8_t *p = getsectiondata(mh, "__TEXT", "__eh_frame", &size);

which always leads directly to the memory crash.

the function is detailed here <​http://opensource.apple.com/source/cctools/cctools-886/libmacho/getsecbyname.c>

this info sent to the function looked OK to me

341 uint8_t *p = getsectiondata(mh, "__TEXT", "__eh_frame", &size);
(gdb) print mh
$10 = (const mach_header_64 *) 0x10000d610
(gdb) print size
$11 = 0
(gdb) print p
$12 = (uint8_t *) 0x0

so I wondered if it could be that *p was an unallocated memory location that the function crashes when trying to write to.

I tried this

    const uint8_t *p = (uint8_t *)malloc(sizeof *p);
    p = getsectiondata(mh, "__TEXT", "__eh_frame", &size);

but that doesn't work either. Still plugging away...

[ken-cunningham-webuse]

here's the crash in getsecbyname.c

Process 87655 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac383 libmacho.1.dylib`getsectiondata + 221 at getsecbyname.c:413, stop reason = step in
    frame #0: 0x00000001001ac383 libmacho.1.dylib`getsectiondata + 221 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) 
Process 87655 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414, stop reason = step in
    frame #0: 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
-> 414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
   417 			}
(lldb) 
Process 87655 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414, stop reason = EXC_BAD_ACCESS (code=1, address=0x1e8c107e0)
    frame #0: 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
-> 414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
   417 			}
(lldb) 
Process 87655 stopped

[ken-cunningham-webuse]

and here's the full set of frame variables just prior to the step that generates the BAD_ACCESS error.

Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ca libmacho.1.dylib`getsectiondata + 36 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac2ca libmacho.1.dylib`getsectiondata + 36 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) frame variable sgp->cmd
(uint32_t) sgp->cmd = <Parent failed to evaluate: variable not available.
>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ce libmacho.1.dylib`getsectiondata + 40 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac2ce libmacho.1.dylib`getsectiondata + 40 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) frame variable sgp->cmd
(uint32_t) sgp->cmd = <Parent failed to evaluate: variable not available.
>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2d2 libmacho.1.dylib`getsectiondata + 44 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac2d2 libmacho.1.dylib`getsectiondata + 44 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2d5 libmacho.1.dylib`getsectiondata + 47 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac2d5 libmacho.1.dylib`getsectiondata + 47 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2d8 libmacho.1.dylib`getsectiondata + 50 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac2d8 libmacho.1.dylib`getsectiondata + 50 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2dd libmacho.1.dylib`getsectiondata + 55 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac2dd libmacho.1.dylib`getsectiondata + 55 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2e3 libmacho.1.dylib`getsectiondata + 61 at getsecbyname.c:412, stop reason = instruction step into
    frame #0: 0x00000001001ac2e3 libmacho.1.dylib`getsectiondata + 61 at getsecbyname.c:412
   409 		slide = 0;
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
-> 412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2e7 libmacho.1.dylib`getsectiondata + 65 at getsecbyname.c:412, stop reason = instruction step into
    frame #0: 0x00000001001ac2e7 libmacho.1.dylib`getsectiondata + 65 at getsecbyname.c:412
   409 		slide = 0;
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
-> 412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
(lldb) frame variable sgp->cmd
(uint32_t) sgp->cmd = 1166624768
(lldb) frame variable sgp->cmd --format string
Invalid format character or name 'string'. Valid values are:
"default"
'B' or "boolean"
'b' or "binary"
'y' or "bytes"
'Y' or "bytes with ASCII"
'c' or "character"
'C' or "printable character"
'F' or "complex float"
's' or "c-string"
'i' or "signed decimal"
'E' or "enumeration"
'x' or "hex"
'f' or "float"
'o' or "octal"
'O' or "OSType"
'U' or "unicode16"
"unicode32"
'u' or "unsigned decimal"
'p' or "pointer"
"char[]"
"int8_t[]"
"uint8_t[]"
"int16_t[]"
"uint16_t[]"
"int32_t[]"
"uint32_t[]"
"int64_t[]"
"uint64_t[]"
"float32[]"
"float64[]"
"uint128_t[]"
'I' or "complex integer"
'a' or "character array"
(lldb) frame variable sgp->cmd --format s
(uint32_t) sgp->cmd = ""
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2e9 libmacho.1.dylib`getsectiondata + 67 at getsecbyname.c:412, stop reason = instruction step into
    frame #0: 0x00000001001ac2e9 libmacho.1.dylib`getsectiondata + 67 at getsecbyname.c:412
   409 		slide = 0;
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
-> 412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
(lldb) frame variable sgp->cmd --format s
(uint32_t) sgp->cmd = ""
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414, stop reason = instruction step into
    frame #0: 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
-> 414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
   417 			}
(lldb) frame variable sgp->cmd --format s
(uint32_t) sgp->cmd = <Parent failed to evaluate: variable not available.
>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2f1 libmacho.1.dylib`getsectiondata + 75 at getsecbyname.c:414, stop reason = instruction step into
    frame #0: 0x00000001001ac2f1 libmacho.1.dylib`getsectiondata + 75 at getsecbyname.c:414
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
-> 414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
   417 			}
(lldb) frame variable sgp->cmd --format s
(uint32_t) sgp->cmd = <Parent failed to evaluate: variable not available.
>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac37c libmacho.1.dylib`getsectiondata + 214 at getsecbyname.c:434, stop reason = instruction step into
    frame #0: 0x00000001001ac37c libmacho.1.dylib`getsectiondata + 214 at getsecbyname.c:434
   431 			    }
   432 			}
   433 		    }
-> 434 		    sgp = (struct segment_command_64 *)((char *)sgp + sgp->cmdsize);
   435 		}
   436 		return(0);
   437 	}
(lldb) frame variable sgp->cmd --format s
(uint32_t) sgp->cmd = <Parent failed to evaluate: variable not available.
>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac380 libmacho.1.dylib`getsectiondata + 218 at getsecbyname.c:434, stop reason = instruction step into
    frame #0: 0x00000001001ac380 libmacho.1.dylib`getsectiondata + 218 at getsecbyname.c:434
   431 			    }
   432 			}
   433 		    }
-> 434 		    sgp = (struct segment_command_64 *)((char *)sgp + sgp->cmdsize);
   435 		}
   436 		return(0);
   437 	}
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac383 libmacho.1.dylib`getsectiondata + 221 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac383 libmacho.1.dylib`getsectiondata + 221 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) frame variable
(const struct mach_header_64 *) mhp = 0x000000010000d610
(const char *) segname = 0x000000010000fcd1 "__TEXT"
(const char *) sectname = 0x000000010000fcd8 "__eh_frame"
(unsigned long *) size = 0x00007fff5fbfecc8
(uint32_t) i = 0
(intptr_t) slide = 0
(segment_command_64 *) sgp = <variable not available>
(uint32_t) j = <variable not available>
(section_64 *) sp = <variable not available>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac386 libmacho.1.dylib`getsectiondata + 224 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac386 libmacho.1.dylib`getsectiondata + 224 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac389 libmacho.1.dylib`getsectiondata + 227 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac389 libmacho.1.dylib`getsectiondata + 227 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac38e libmacho.1.dylib`getsectiondata + 232 at getsecbyname.c:413, stop reason = instruction step into
    frame #0: 0x00000001001ac38e libmacho.1.dylib`getsectiondata + 232 at getsecbyname.c:413
   410 		sp = 0;
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
-> 413 		for(i = 0; i < mhp->ncmds; i++){
   414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414, stop reason = instruction step into
    frame #0: 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
-> 414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
   417 			}
(lldb) frame variable
(const struct mach_header_64 *) mhp = 0x000000010000d610
(const char *) segname = 0x000000010000fcd1 "__TEXT"
(const char *) sectname = 0x000000010000fcd8 "__eh_frame"
(unsigned long *) size = 0x00007fff5fbfecc8
(uint32_t) i = 0
(intptr_t) slide = 0
(segment_command_64 *) sgp = <variable not available>
(uint32_t) j = <variable not available>
(section_64 *) sp = <variable not available>
(lldb) frame variable sgp->cmd --format s
(uint32_t) sgp->cmd = <Parent failed to evaluate: variable not available.
>
(lldb) thread step-inst
Process 88388 stopped
* thread #1: tid = 0x2d03, 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414, stop reason = EXC_BAD_ACCESS (code=1, address=0x1e8c10800)
    frame #0: 0x00000001001ac2ed libmacho.1.dylib`getsectiondata + 71 at getsecbyname.c:414
   411 		sgp = (struct segment_command_64 *)
   412 		      ((char *)mhp + sizeof(struct mach_header_64));
   413 		for(i = 0; i < mhp->ncmds; i++){
-> 414 		    if(sgp->cmd == LC_SEGMENT_64){
   415 			if(strcmp(sgp->segname, "__TEXT") == 0){
   416 			    slide = (uintptr_t)mhp - sgp->vmaddr;
   417 			}
(lldb) thread step-inst

[jeremyhu (Jeremy Huddleston Sequoia)]

Try libunwind changes in 0fda16369fb0faad9f0e26a9820a16927cfcede4 and libcxxabi changes in 1ad7738a54d1bb11c98455154e6d625680f49b2d. That should fix libunwind on Leopard.

[jeremyhu (Jeremy Huddleston Sequoia)]

Also note that you'll probably be bit by ​https://llvm.org/bugs/show_bug.cgi?id=30858

[kencu (Ken)]

In 133e9a648ed94354e30cf13f13d202c76f21f8b3/macports-ports:

babl: tweak gcc blacklisting

allows builds with newer gcc version e.g. on PPC
closes: #49764

[barracuda156]

Replying to udbraumann:

Is the cctools port installed and active on your 10.6.8 box when you are seeing that error?

I am afraid, that Xcode 4.2 providing llvm-gcc-4.2 somehow is interferring with cctools, so that the assembler for ppc is not being found.

Yes, you should either stay on XCode 3.2.x or otherwise use something like this procedure: ​https://stackoverflow.com/questions/5333490/how-can-we-restore-ppc-ppc64-as-well-as-full-10-4-10-5-sdk-support-to-xcode-4 And then make sure that Macports uses gcc-4.2 for ppc code, since llvm-gcc-4.2 (which is symlinked to /usr/bin/gcc by default) fails.