#49764 closed enhancement (fixed)
babl @0.1.14 falls back to clang-3.4 which is not functional on PPC platforms
Reported by: | udbraumann | Owned by: | dbevans (David B. Evans) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | powerpc | Cc: | jeremyhu (Jeremy Huddleston Sequoia), larryv (Lawrence Velázquez), mww@…, ryandesign (Ryan Carsten Schmidt), khepler, mojca (Mojca Miklavec) |
Port: | clang34 |
Description
$ 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?
Attachments (2)
Change History (48)
comment:1 Changed 9 years ago by dbevans (David B. Evans)
Cc: | devans@… removed |
---|---|
Owner: | changed from macports-tickets@… to devans@… |
Status: | new → assigned |
Version: | 2.3.4 |
comment:2 Changed 9 years ago by dbevans (David B. Evans)
Cc: | jeremyhu@… ryandesign@… added |
---|
comment:3 Changed 9 years ago by dbevans (David B. Evans)
Cc: | larryv@… mww@… added |
---|
comment:4 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | powerpc added; PPC removed |
---|
comment:5 follow-up: 6 Changed 9 years ago by 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.
comment:6 follow-up: 7 Changed 9 years ago by 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.
comment:7 Changed 9 years ago by 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 usinggcc5
.clang-3.4
builds on PPC, but it is not functional! I leave it to you as expert(s) what mechanism is best to includegcc5
as replacement for PPC. compiler.fallback is only effective if a certain required compiler, sayclang-3.*
is blacklisted for a certain platform?I am sure that not all ports requiring
clang-3.*
(andllvm-3.*
) can be built using gcc5 on PPC, but e.g.py27-gobject3
orgnome-keyring
andbabl
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.
comment:8 follow-up: 10 Changed 9 years ago by 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.
comment:9 Changed 9 years ago by 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
comment:10 Changed 9 years ago by 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
comment:11 follow-up: 12 Changed 9 years ago by 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?
comment:12 follow-up: 46 Changed 9 years ago by 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.
comment:13 Changed 9 years ago by 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.
comment:14 follow-ups: 15 16 Changed 9 years ago by 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!
comment:15 follow-up: 17 Changed 9 years ago by 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?
comment:16 follow-up: 19 Changed 9 years ago by 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.
comment:17 Changed 9 years ago by 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.
comment:18 Changed 9 years ago by dbevans (David B. Evans)
Port: | clang34 added; babl removed |
---|---|
Summary: | babl @0.1.14 should not require clang-3.4 → babl @0.1.14 falls back to clang-3.4 which is not functional on PPC platforms |
comment:19 Changed 9 years ago by 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).
comment:20 follow-up: 21 Changed 9 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Please file a bug report for your llvm-3.8 build failure.
comment:21 Changed 9 years ago by 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.
comment:24 Changed 8 years ago by 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
comment:25 Changed 8 years ago by 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.
comment:26 Changed 8 years ago by 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
comment:27 follow-up: 28 Changed 8 years ago by 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
comment:28 Changed 8 years ago by larryv (Lawrence Velázquez)
You aren’t using libunwind. Note that your C++ library is libstdc++, not libc++.
comment:29 Changed 8 years ago by 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.
comment:30 follow-up: 33 Changed 8 years ago by 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.
comment:31 follow-up: 32 Changed 8 years ago by 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
comment:32 Changed 8 years ago by 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.
comment:33 Changed 8 years ago by 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.
comment:34 follow-up: 35 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yea, the libunwind bug is the blocker here. That's exactly what I said in the 'Leopard (ppc)' section on the LibcxxOnOlderSystems wiki ;)
I suggest you dive into http://www.llvm.org/bugs/show_bug.cgi?id=22270 for that.
comment:35 Changed 8 years ago by 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
comment:36 Changed 8 years ago by 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
comment:37 Changed 8 years ago by 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.
comment:38 Changed 8 years ago by 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
Changed 8 years ago by ken-cunningham-webuse
Attachment: | gdb-log-test_throw.log added |
---|
gdb log of test_throw.cxx
comment:39 Changed 8 years ago by 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.
Changed 8 years ago by ken-cunningham-webuse
Attachment: | gdb-log-another-try.log added |
---|
comment:40 Changed 8 years ago by 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...
comment:41 Changed 8 years ago by 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
comment:42 Changed 8 years ago by 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
comment:43 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Try libunwind changes in 0fda16369fb0faad9f0e26a9820a16927cfcede4 and libcxxabi changes in 1ad7738a54d1bb11c98455154e6d625680f49b2d. That should fix libunwind on Leopard.
comment:44 Changed 8 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Also note that you'll probably be bit by https://llvm.org/bugs/show_bug.cgi?id=30858
comment:45 Changed 7 years ago by kencu (Ken)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:46 Changed 3 years ago by 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.
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.