Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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)

main.log (8.8 KB) - added by cline@… 10 years ago.
log of libffi failing to build on OS X 10.6.8
main.2.log (8.9 KB) - added by chethil.sudheesh@… 10 years ago.
main.log

Download all attachments as: .zip

Change History (65)

comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Description: modified (diff)
Type: submissiondefect

Please attach the main.log file.

comment:2 Changed 10 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

Changed 10 years ago by cline@…

Attachment: main.log added

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

Last edited 10 years ago by udbraumann (previous) (diff)

comment:4 Changed 10 years ago by null-macports.org@…

Cc: null-macports.org@… added

Cc Me! On 10.5.8 Intel

Last edited 10 years ago by null-macports.org@… (previous) (diff)

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 failedlibffi @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 systemslibffi @3.1 fails to build on 32-bit systems

comment:7 Changed 10 years ago by barry@…

Cc: barry@… added

Cc Me!

comment:8 Changed 10 years ago by chethil.sudheesh@…

Cc: chethil.sudheesh@… added

Cc Me!

comment:9 Changed 10 years ago by chethil.sudheesh@…

Also Fails on my mac (10.5.8 Intel Core 2 Duo).

comment:10 Changed 10 years ago by Schamschula (Marius Schamschula)

I just sent this info to the developer.

comment:11 Changed 10 years ago by StanSanderson

Cc: stansand@… added

Cc Me!

comment:12 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 in reply to:  12 ; 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!

Changed 10 years ago by chethil.sudheesh@…

Attachment: main.2.log added

main.log

comment:14 Changed 10 years ago by chethil.sudheesh@…

My problem is not solved. Attached above my main.log.

comment:15 Changed 10 years ago by null-macports.org@…

Worked for me. 10.5.8 Intel 32bit. Thanks!

Last edited 10 years ago by null-macports.org@… (previous) (diff)

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.

Version 0, edited 10 years ago by semaphore45@… (next)

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:19 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:20 Changed 10 years ago by steven@…

Cc: steven@… added

Cc Me!

comment:21 Changed 10 years ago by nano103

Cc: nano103@… added

Cc Me!

comment:22 Changed 10 years ago by jon@…

Cc: jon@… added

Cc Me!

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:24 Changed 10 years ago by daniel.laflamme@…

Cc: daniel.laflamme@… added

Cc Me!

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:30 Changed 10 years ago by semaphore45@…

Cc: semaphore45@… added

Cc Me!

comment:31 in reply to:  10 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to mschamschula@…:

I just sent this info to the developer.

URL, please.

comment:32 Changed 10 years ago by Schamschula (Marius Schamschula)

libffi has no bug tracker. I sent an e-mail to the developer: green@….

comment:33 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 in reply to:  33 ; 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 in reply to:  34 ; 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:36 Changed 10 years ago by bitpup

Cc: wheeltong@… added

Cc Me!

comment:37 Changed 10 years ago by dliessi (Davide Liessi)

Cc: davide.liessi@… added

Cc Me!

comment:38 Changed 10 years ago by mopihopi

Cc: mopihopi@… added

Cc Me!

comment:39 Changed 10 years ago by saile@…

Cc: saile@… added

Cc Me!

comment:40 in reply to:  35 Changed 10 years ago by galitsyn@…

Cc Me!

comment:41 Changed 10 years ago by hanibal_lector@…

Cc: hanibal_lector@… added

Cc Me!

comment:42 in reply to:  32 ; 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:43 Changed 10 years ago by aiguzhinov@…

Cc: aiguzhinov@… added

Cc Me!

comment:44 in reply to:  42 ; 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 in reply to:  13 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.3

Works 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 in reply to:  44 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
Last edited 10 years ago by jmroot (Joshua Root) (previous) (diff)

comment:47 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Cc: jeremyhu@… added

Cc Me!

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"
}
Last edited 10 years ago by cooljeanius (Eric Gallager) (previous) (diff)

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 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 in reply to:  52 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: newclosed

comment:58 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: closedreopened

Actually, reverted. I messed that up and will figure out the proper fix later, but at least we know the problem.

comment:59 Changed 10 years ago by aiguzhinov@…

Cc: aiguzhinov@… removed

Cc Me!

comment:60 Changed 10 years ago by aiguzhinov@…

Cc: aiguzhinov@… added

Cc Me!

comment:61 Changed 10 years ago by aiguzhinov@…

Cc: aiguzhinov@… removed

Cc Me!

comment:62 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)

Resolution: fixed
Status: reopenedclosed

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 in reply to:  62 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!

Note: See TracTickets for help on using tickets.