#44170 closed defect (fixed)
libffi @3.1 fails to build on 32-bit systems
Reported by: | opr_systems@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.3.1 |
Keywords: | LP32 | Cc: | Schamschula (Marius Schamschula), mkae (Marko Käning), udbraumann, null-macports.org@…, barry@…, chethil.sudheesh@…, StanSanderson, cooljeanius (Eric Gallager), steven@…, nano103, jon@…, daniel.laflamme@…, semaphore45@…, bitpup, dliessi (Davide Liessi), mopihopi, saile@…, hanibal_lector@…, jeremyhu (Jeremy Huddleston Sequoia) |
Port: | libffi |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
sudo port clean libffi ---> Cleaning libffi sudo port install libffi ---> Fetching archive for libffi ---> Attempting to fetch libffi-3.1_0.darwin_9.i386.tbz2 from http://lil.fr.packages.macports.org/libffi
An blah; blah; blah.. until
---> Fetching distfiles for libffi ---> Verifying checksums for libffi ---> Extracting libffi ---> Configuring libffi ---> Building libffi Error: org.macports.build for port libffi returned: command execution failed Please see the log file for port libffi for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libffi/libffi/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port libffi failed
Attachments (2)
Change History (65)
comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Type: | submission → defect |
Changed 10 years ago by cline@…
log of libffi failing to build on OS X 10.6.8
comment:3 Changed 10 years ago by udbraumann
Cc: | braumann@… added |
---|
Cc Me!
also fails on 10.5.8 on a PPC
comment:4 Changed 10 years ago by null-macports.org@…
Cc: | null-macports.org@… added |
---|
Cc Me! On 10.5.8 Intel
comment:5 Changed 10 years ago by jmroot (Joshua Root)
Cc: | mschamschula@… added |
---|---|
Keywords: | i386 added |
Owner: | changed from macports-tickets@… to ryandesign@… |
Summary: | Processing of port libffi failed → libffi @3.1 fails to build on i386 systems |
comment:6 Changed 10 years ago by jmroot (Joshua Root)
Keywords: | LP32 added; i386 removed |
---|---|
Summary: | libffi @3.1 fails to build on i386 systems → libffi @3.1 fails to build on 32-bit systems |
comment:9 Changed 10 years ago by chethil.sudheesh@…
Also Fails on my mac (10.5.8 Intel Core 2 Duo).
comment:10 follow-up: 31 Changed 10 years ago by Schamschula (Marius Schamschula)
I just sent this info to the developer.
comment:12 follow-up: 13 Changed 10 years ago by pietvo (Pieter van Oostrum)
I got it upgraded with
sudo port clean libffi sudo port upgrade libffi configure.compiler=macports-clang-3.3
comment:13 follow-up: 45 Changed 10 years ago by StanSanderson
Replying to piet@…:
I got it upgraded with
sudo port clean libffi sudo port upgrade libffi configure.compiler=macports-clang-3.3
Works for me also- OS 10.6.8, 2 GHz Intel Core Duo (early iMac). Thanks!
comment:14 Changed 10 years ago by chethil.sudheesh@…
My problem is not solved. Attached above my main.log.
comment:16 Changed 10 years ago by mopihopi
I encountered the same issue on my 64-bit OS X 10.6.8 system upgrading to libffi@3.1_0+universal
(x86_64 i386).
sudo port upgrade libffi configure.compiler=macports-clang-3.3
fixed it.
comment:17 Changed 10 years ago by semaphore45@…
Solution sudo port upgrade libffi configure.compiler=macports-clang-3.3 fixed it for me, too.
BTW it was not limited to 32 bit system. 64 bit is also affected. 10.6.8 here.
comment:18 Changed 10 years ago by barry@…
Unfortunately, it doesn't work for me:
DEBUG: Searching for dependency: clang-3.3 DEBUG: Didn't find receipt, going to depspec regex for: clang-3.3 DEBUG: too many nested evaluations (infinite loop?) while executing "lshift args" (procedure "try" line 7) invoked from within "try { seek $fd $offset gets $fd line set name [lindex $line 0] set len [lindex $line ..." (procedure "mportlookup" line 21) invoked from within "mportlookup $portname" Error: port lookup failed: too many nested evaluations (infinite loop?) To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets
comment:23 Changed 10 years ago by jon@…
It appears that the work-around fails for me since I've been waiting for bugs to fix building of llvm/clang on my system and libffi is now a dependency of llvm. Specific failure on attempting it:
$ sudo port upgrade libffi configure.compiler=macports-clang-3.3 Error: port lookup failed: too many nested evaluations (infinite loop?) To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets
comment:25 Changed 10 years ago by daniel.laflamme@…
sudo port clean libffi followed by sudo port upgrade libffi configure.compiler=macports-clang-3.3 resolved it for me as well.
comment:26 Changed 10 years ago by udbraumann
Since clang practically is not functional on PPC platforms, I would be happy if someone has an idea what to do. gcc48 is not working since universal build capabilities are required for libffi (at least for my installation).
comment:27 Changed 10 years ago by pamorin@…
No fix for me, doing a first install
sudo port upgrade libffi configure.compiler=macports-clang-3.3 Error: libffi is not installed
comment:28 Changed 10 years ago by jon@…
libffi being broken is now blocking me from building most ports, even hicolor-icon-theme.
comment:29 Changed 10 years ago by semaphore45@…
Also fails on 64-bit system, namely Snow Leopard. MacPorts currently unusable due to this essential, failing dependency.
comment:31 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
comment:32 follow-up: 42 Changed 10 years ago by Schamschula (Marius Schamschula)
libffi has no bug tracker. I sent an e-mail to the developer: green@….
comment:33 follow-up: 34 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Oh dear. Well I blacklisted compilers that aren't working in r121730 but I haven't checked if that helped the universal build on Snow Leopard. And unfortunately it still leaves some platforms (Leopard and Tiger) without a working compiler for this port.
comment:34 follow-up: 35 Changed 10 years ago by cooljeanius (Eric Gallager)
Replying to ryandesign@…:
Oh dear. Well I blacklisted compilers that aren't working in r121730 but I haven't checked if that helped the universal build on Snow Leopard.
Just tried building universal on Snow Leopard, the blacklist seems to be working at least:
DEBUG: Using compiler 'Xcode Clang'
Still fails with the same error though:
libtool: compile: ccache /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/opt/local/include -I. -I../include -Iinclude -I../src -pipe -Os -arch i386 -c ../src/x86/win32.S -o src/x86/.libs/win32.o ../src/x86/win32.S:1285:section difference relocatable subtraction expression, ".LFE5" minus ".LFB5" using a symbol at the end of section will not produce an assembly time constant ../src/x86/win32.S:1285:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = .LFE5 - .LFB5 ../src/x86/win32.S:1277:section difference relocatable subtraction expression, ".LEFDE5" minus ".LASFDE5" using a symbol at the end of section will not produce an assembly time constant ../src/x86/win32.S:1277:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = .LEFDE5 - .LASFDE5 ../src/x86/win32.S:unknown:missing indirect symbols for section (__IMPORT,__jump_table) clang: error: assembler command failed with exit code 1 (use -v to see invocation)
although that might be due to ccache
using the gcc stuff from my last failed build; let me disable ccache, clean, and then try again...
comment:35 follow-up: 40 Changed 10 years ago by cooljeanius (Eric Gallager)
Replying to egall@…:
although that might be due to
ccache
using the gcc stuff from my last failed build; let me disable ccache, clean, and then try again...
Turns out nope, it was not a ccache
issue; I tried doing it manually and ran into the same issues. Here it is with the -v
flag that it recommended trying:
$ sudo /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/opt/local/include -I. -I../include -Iinclude -I../src -pipe -Os -arch i386 -c ../src/x86/win32.S -v -o src/x86/.libs/win32.o Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn) Target: i386-apple-darwin10 Thread model: posix "/usr/bin/clang" -cc1 -triple i386-apple-darwin10.0.0 -E -disable-free -disable-llvm-verifier -main-file-name win32.S -pic-level 1 -mdisable-fp-elim -target-cpu yonah -target-linker-version 97.17 -v -resource-dir /usr/bin/../lib/clang/1.7 -D HAVE_CONFIG_H -I . -I .. -I . -I ../include -I include -I ../src -I /opt/local/include -I . -I ../include -I include -I ../src -Os -ferror-limit 19 -fmessage-length 209 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ELN12u.s -x assembler-with-cpp ../src/x86/win32.S clang -cc1 version 1.7 based upon llvm 2.9svn hosted on x86_64-apple-darwin10 ignoring duplicate directory "." ignoring duplicate directory "." ignoring duplicate directory "../include" ignoring duplicate directory "include" ignoring duplicate directory "../src" #include "..." search starts here: #include <...> search starts here: . .. ../include include ../src /opt/local/include /usr/local/include /usr/bin/../lib/clang/1.7/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/usr/bin/as" -arch i386 -force_cpusubtype_ALL -o src/x86/.libs/win32.o /tmp/cc-ELN12u.s ../src/x86/win32.S:1285:section difference relocatable subtraction expression, ".LFE5" minus ".LFB5" using a symbol at the end of section will not produce an assembly time constant ../src/x86/win32.S:1285:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = .LFE5 - .LFB5 ../src/x86/win32.S:1277:section difference relocatable subtraction expression, ".LEFDE5" minus ".LASFDE5" using a symbol at the end of section will not produce an assembly time constant ../src/x86/win32.S:1277:use a symbol with a constant value created with an assignment instead of the expression, L_const_sym = .LEFDE5 - .LASFDE5 ../src/x86/win32.S:unknown:missing indirect symbols for section (__IMPORT,__jump_table) clang: error: assembler command failed with exit code 1 (use -v to see invocation)
As you can see it is still using /usr/bin/as
, which is the same assembler that gcc would have been using. Passing the -integrated-as
flag to clang
allows the file to compile successfully:
$ sudo /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I/opt/local/include -I. -I../include -Iinclude -I../src -pipe -Os -arch i386 -c ../src/x86/win32.S -v -integrated-as -o src/x86/.libs/win32.o Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn) Target: i386-apple-darwin10 Thread model: posix "/usr/bin/clang" -cc1 -triple i386-apple-darwin10.0.0 -E -disable-free -disable-llvm-verifier -main-file-name win32.S -pic-level 1 -mdisable-fp-elim -target-cpu yonah -target-linker-version 97.17 -v -resource-dir /usr/bin/../lib/clang/1.7 -D HAVE_CONFIG_H -I . -I .. -I . -I ../include -I include -I ../src -I /opt/local/include -I . -I ../include -I include -I ../src -Os -ferror-limit 19 -fmessage-length 209 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-8SbMyN.s -x assembler-with-cpp ../src/x86/win32.S clang -cc1 version 1.7 based upon llvm 2.9svn hosted on x86_64-apple-darwin10 ignoring duplicate directory "." ignoring duplicate directory "." ignoring duplicate directory "../include" ignoring duplicate directory "include" ignoring duplicate directory "../src" #include "..." search starts here: #include <...> search starts here: . .. ../include include ../src /opt/local/include /usr/local/include /usr/bin/../lib/clang/1.7/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/usr/bin/clang" -cc1as -triple i386-apple-darwin10.0.0 -filetype obj -o src/x86/.libs/win32.o /tmp/cc-8SbMyN.s
comment:42 follow-up: 44 Changed 10 years ago by jmroot (Joshua Root)
Replying to mschamschula@…:
libffi has no bug tracker. I sent an e-mail to the developer: green@….
What’s wrong with https://github.com/atgreen/libffi/issues?
comment:44 follow-up: 46 Changed 10 years ago by hanibal_lector@…
Replying to jmr@…:
Replying to mschamschula@…:
libffi has no bug tracker. I sent an e-mail to the developer: green@….
What’s wrong with https://github.com/atgreen/libffi/issues?
First of all i would please you all to download the package of libffi-3.1 yourself or copy it from the build directory, because I am nearly sure that the problem is a macports one. I take the package from here ftp://sourceware.org/pub/libffi/libffi-3.1.tar.gz and compiled it successfully on my mac with macports libs. I also tried to get the environment settings from macports main.log, one for x86 one for x64 to reproduce the failure without luck. For x64:
#!/bin/bash CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libffi/libffi/work/.CC_PRINT_OPTIONS' CPATH='/macports/include' LIBRARY_PATH='/macports/lib' MACOSX_DEPLOYMENT_TARGET='10.6' CC='/usr/bin/clang' CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libffi/libffi/work/.CC_PRINT_OPTIONS' CFLAGS='-pipe -Os -arch x86_64' CPATH='/macports/include' CPPFLAGS='-I/macports/include' CXX='/usr/bin/llvm-g++-4.2' CXXFLAGS='-pipe -Os -arch x86_64' F90FLAGS='-pipe -Os -m64' FCFLAGS='-pipe -Os -m64' FFLAGS='-pipe -Os -m64' INSTALL='/usr/bin/install -c' LDFLAGS='-L/macports/lib -Wl,-headerpad_max_install_names -arch x86_64' LIBRARY_PATH='/macports/lib' MACOSX_DEPLOYMENT_TARGET='10.6' NM='/usr/bin/nm' OBJC='/usr/bin/clang' OBJCFLAGS='-pipe -Os -arch x86_64' OBJCXX='/usr/bin/llvm-g++-4.2' OBJCXXFLAGS='-pipe -Os' cd libffi-3.1 make clean #./configure ./configure --prefix=/Spezial/Dev/libffi/build --disable-dependency-tracking --disable-dependency-tracking --disable-dependency-tracking make >> test_.log make install cd ..
x86:
#!/bin/bash CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/macports/var/macports/build/_macports_var_macports_sources$ CPATH='/macports/include' LIBRARY_PATH='/macports/lib' MACOSX_DEPLOYMENT_TARGET='10.6' CC='/usr/bin/clang' CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/macports/var/macports/build/_macports_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libffi/libffi/work/.CC_PRINT_OPTIONS' CFLAGS='-pipe -Os -arch i386' CPATH='/macports/include' CPPFLAGS='-I/macports/include' CXX='/usr/bin/llvm-g++-4.2' CXXFLAGS='-pipe -Os -arch i386' F90FLAGS='-pipe -Os -m32' FCFLAGS='-pipe -Os -m32' FFLAGS='-pipe -Os -m32' INSTALL='/usr/bin/install -c' LDFLAGS='-L/macports/lib -Wl,-headerpad_max_install_names -arch i386' LIBRARY_PATH='/macports/lib' MACOSX_DEPLOYMENT_TARGET='10.6' NM='/usr/bin/nm' OBJC='/usr/bin/clang' OBJCFLAGS='-pipe -Os -arch i386' OBJCXX='/usr/bin/llvm-g++-4.2' OBJCXXFLAGS='-pipe -Os' cd libffi-3.1 make clean #./configure ./configure --prefix=/Spezial/Dev/libffi/build --disable-dependency-tracking --disable-dependency-tracking --disable-dependency-tracking make >> test_.log make install cd ..
Maybe some one of you can reproduce the failure inside of macports.
comment:45 Changed 10 years ago by hanibal_lector@…
Replying to stansand@…:
Replying to piet@…:
I got it upgraded with
sudo port clean libffi sudo port upgrade libffi configure.compiler=macports-clang-3.3Works for me also- OS 10.6.8, 2 GHz Intel Core Duo (early iMac). Thanks!
For me too. I also could also verify it with "configure.compiler=macports-clang-3.4" - I will check if it works with macports-clang-3.2. Otherwise if you have not any macports-clang-3.* installed you have to install it with
sudo port -bf install clang-3.3
otherwise you get the conflict that libffi ist not installed. "-f" is maybe not needed but i would advise it.
comment:46 Changed 10 years ago by jmroot (Joshua Root)
Replying to hanibal_lector@…:
First of all i would please you all to download the package of libffi-3.1 yourself or copy it from the build directory, because I am nearly sure that the problem is a macports one. I take the package from here ftp://sourceware.org/pub/libffi/libffi-3.1.tar.gz and compiled it successfully on my mac with macports libs. I also tried to get the environment settings from macports main.log, one for x86 one for x64 to reproduce the failure without luck.
I just checked, and I can easily reproduce the build failure outside of macports in a 10.6 VM like this:
env CFLAGS="-arch i386" ./configure make
comment:48 Changed 10 years ago by cooljeanius (Eric Gallager)
r122003 tried to address this, but it just leads to the following on my system:
---> Configuring libffi for architecture x86_64 Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option DEBUG: Environment: CC='ccache /usr/bin/gcc-4.2'
And then it fails with the same error. Personally I would have tried one or both of the following:
if {[string match *clang* ${configure.compiler}]} { configure.cflags-append -integrated-as }
and/or:
if {[string match *clang* ${configure.compiler}]} { configure.env-append CCAS="${configure.compiler}" # or maybe: configure.env-append AS="${configure.compiler} -cc1as" }
comment:49 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yeah, that's probably a good idea based on comment #40. Care to send a patch? My SL box is occupied with many other things right now. If not, I'll take a look later.
comment:50 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
I think you mean comment:35?
I can give this a try on Snow Leopard now.
comment:51 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Really, though, the developers of libffi need to fix this, since the contemplated workaround above won't help Tiger or Leopard since they don't come with clang.
comment:52 follow-up: 53 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I gave it a try by hand with /usr/bin/clang -integrated-as, and it then fails to link. Xcode 3.2.6's ld just segfaults, and I think this is the "ld segfaults when emitting a warning" crash that was fixed a couple years ago... and indeed "our" ld shows the warning:
~/src/macports/dports/devel/libffi/work/libffi-3.1-i386/x86_64-apple-darwin10.8.0 $ /usr/bin/ld -dynamic -dylib -dylib_compatibility_version 7 -dylib_current_version 7.2 -arch i386 -dylib_install_name /opt/local/lib/libffi.6.dylib -macosx_version_min 10.6.0 -o .libs/libffi.6.dylib -L/opt/local/lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o src/x86/.libs/win32.o -headerpad_max_install_names -headerpad_max_install_names -single_module -lSystem /usr/bin/../lib/clang/1.7/lib/darwin/libclang_rt.eprintf.a Segmentation fault ~/src/macports/dports/devel/libffi/work/libffi-3.1-i386/x86_64-apple-darwin10.8.0 $ /opt/local/bin/ld -dynamic -dylib -dylib_compatibility_version 7 -dylib_current_version 7.2 -arch i386 -dylib_install_name /opt/local/lib/libffi.6.dylib -macosx_version_min 10.6.0 -o .libs/libffi.6.dylib -L/opt/local/lib -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o src/x86/.libs/win32.o -headerpad_max_install_names -headerpad_max_install_names -single_module -lSystem /usr/bin/../lib/clang/1.7/lib/darwin/libclang_rt.eprintf.a ld: warning: could not create compact unwind for .LFB3: non-standard register 5 being saved in prolog
Why not just omit win32 from libffi? Do we actually need it for something?
comment:53 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Replying to jeremyhu@…:
Why not just omit win32 from libffi? Do we actually need it for something?
It looks like it wasn't there in 3.0 and was added for 3.1, so I suspect it should be "safe" to just remove it until upstream fixes their game:
commit afee53738a995e23bd2f89fd0f7b30b380566106 Merge: 7d24785 b2d610e Author: Anthony Green <green@moxielogic.com> Date: Tue Mar 25 16:12:35 2014 -0400 Merge pull request #106 from joshtriplett/darwin-award [3.1 blocker] Update OS X build system to include win32.S on 32-bit
comment:54 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
I don't know what "win32" is or if we need it. But instead of disabling bits of their software, why don't we report the problem to them and give them the opportunity to resolve it properly, like we usually do? I understand we've sent them one email, but we should file a bug report in the issue tracker mentioned above so that we can track their response, if any.
comment:55 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
I also just emailed Josh about that merge to figure out why it was needed in the first place..
comment:56 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:57 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:58 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Actually, reverted. I messed that up and will figure out the proper fix later, but at least we know the problem.
comment:62 follow-up: 63 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Ok, r122079 this time should be good as that should address the issue of older toolchains failing to compile. Newer toolchains were just stuffing the eh_frame into the jump table. Now, we just omit it everywhere, and seem to be fine for now. Upstream should fix the eh frame in the referenced bug, and we'll inherit the fix when it's ready.
comment:63 Changed 10 years ago by udbraumann
Replying to jeremyhu@…:
I am happy to inform you that the new libffi @3.1_3+universal
could be build on my 10.5.8 PPC. Thanks a lot, Jeremy!
Please attach the main.log file.