libffi @3.1 fails to build on 32-bit systems

[opr_systems@…]

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

[ryandesign (Ryan Carsten Schmidt)]

Please attach the main.log file.

[mkae (Marko Käning)]

Cc Me!

[cline@…]

log of libffi failing to build on OS X 10.6.8

[udbraumann]

Cc Me!

also fails on 10.5.8 on a PPC

[null-macports.org@…]

Cc Me! On 10.5.8 Intel

[barry@…]

Cc Me!

[chethil.sudheesh@…]

Cc Me!

[chethil.sudheesh@…]

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

[Schamschula (Marius Schamschula)]

I just sent this info to the developer.

[StanSanderson]

Cc Me!

[pietvo (Pieter van Oostrum)]

I got it upgraded with

sudo port clean libffi
sudo port upgrade libffi configure.compiler=macports-clang-3.3

[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!

[chethil.sudheesh@…]

main.log

[chethil.sudheesh@…]

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

[null-macports.org@…]

Worked for me. 10.5.8 Intel 32bit. Thanks!

[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.

[semaphore45@…]

Solution sudo port upgrade libffi configure.compiler=macports-clang-3.3 fixed it for me, too.

[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

[cooljeanius (Eric Gallager)]

Cc Me!

[steven@…]

Cc Me!

[nano103]

Cc Me!

[jon@…]

Cc Me!

[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

[daniel.laflamme@…]

Cc Me!

[daniel.laflamme@…]

sudo port clean libffi followed by sudo port upgrade libffi configure.compiler=macports-clang-3.3 resolved it for me as well.

[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).

[pamorin@…]

No fix for me, doing a first install

sudo port upgrade libffi configure.compiler=macports-clang-3.3
Error: libffi is not installed

[jon@…]

libffi being broken is now blocking me from building most ports, even hicolor-icon-theme.

[semaphore45@…]

Also fails on 64-bit system, namely Snow Leopard. MacPorts currently unusable due to this essential, failing dependency.

[semaphore45@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to mschamschula@…:

I just sent this info to the developer.

URL, please.

[Schamschula (Marius Schamschula)]

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

[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.

[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...

[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

[bitpup]

Cc Me!

[dliessi (Davide Liessi)]

Cc Me!

[mopihopi]

Cc Me!

[saile@…]

Cc Me!

[galitsyn@…]

Cc Me!

[hanibal_lector@…]

Cc Me!

[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?

[aiguzhinov@…]

Cc Me!

[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.

[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.

[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

[jeremyhu (Jeremy Huddleston Sequoia)]

Cc Me!

[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"
}

[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.

[ryandesign (Ryan Carsten Schmidt)]

I think you mean comment:35?

I can give this a try on Snow Leopard now.

[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.

[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?

[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

[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.

[jeremyhu (Jeremy Huddleston Sequoia)]

I also just emailed Josh about that merge to figure out why it was needed in the first place..

[jeremyhu (Jeremy Huddleston Sequoia)]

​https://github.com/atgreen/libffi/issues/128

[jeremyhu (Jeremy Huddleston Sequoia)]

r122076

[jeremyhu (Jeremy Huddleston Sequoia)]

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

[aiguzhinov@…]

Cc Me!

[aiguzhinov@…]

Cc Me!

[aiguzhinov@…]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

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.

[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!