llvm-3.3: still linked against old libffi

[mrkapqa]

hello,

on leopard ppc 10.5.8

wget fails to build with error

Failed to build legacy-support: command execution failed

thank you

[reneeotten (Renee Otten)]

the error appears to be

:info:build dyld: Library not loaded: /opt/local/lib/libffi.6.dylib
126	:info:build   Referenced from: /opt/local/libexec/llvm-3.3/lib/libLTO.dylib
127	:info:build   Reason: image not found
128	:info:build /usr/bin/gcc-4.2 -c -Iinclude -Os -arch ppc  src/best_fchdir.c -o src/best_fchdir.o
129	:info:build /bin/sh: line 1:   708 Trace/BPT trap          ${ld} -r "${output}.inode32.${arch}" "${output}.inode32unix2003.${arch}" "${output}.inode64unix2003.${arch}" -o "${output}.${arch}"
130	:info:build make: *** [src/fdopendir.dl.o] Error 133
131	:info:build make: *** Waiting for unfinished jobs....

[kencu (Ken)]

here is your issue:

125     :info:build dyld: Library not loaded: /opt/local/lib/libffi.6.dylib
126	:info:build   Referenced from: /opt/local/libexec/llvm-3.3/lib/libLTO.dylib
127	:info:build   Reason: image not found

I assume you have libffi installed. That was updated and the library name changed.

So - to fix this properly you'll need to rebuild llvm-3.3 against the new libffi. Uninstall llvm-3.3 and then reinstall it.

To fix this for the moment you could make a symlink from the new libffi name to the old libffi name. Just do the right fix as soon as you have a moment.

[kencu (Ken)]

Sorry Rene, stepped on your toe. Will fix

[kencu (Ken)]

llvm-3.3 was already revbumped for the libffi update, so presumably you picked up an older version or in some way have a local disconnect.

​https://github.com/macports/macports-ports/commit/12e92d7d6c63af6a3f8dda4dc950d9e446d8e64c#diff-06d014df8a437e922d5b7b5e9041dde20e3ba656b225991cdab766bc7a5a1e57

ie there is nothing to fix in the ports tree.

[mascguy (Christopher Nielsen)]

Related ticket: issue:63443

[mascguy (Christopher Nielsen)]

Perhaps all foundational toolchain components should be updated to reference ${prefix}/lib/libffi.dylib?

Even if it's necessary to do it after-the-fact via install_name_tool - and perhaps that would be easier than changing configure/build options - it needs to be done.

Alternatively, link against the static lib, assuming there aren't any technical barriers to doing that. Or use a different libffi port, dedicated to LLVM and friends. libffi-bootstrap perhaps?

[Christopher Nielsen <mascguy@…>]

In 6fb2ae6631b642ed4fcf13d0531348e51d29f36c/macports-ports (master):

libffi: symlink via prev major version

• Absolutely critical, to avoid temporary toolchain breakage

Closes: #63443
Closes: #63453
See: #63378

[mascguy (Christopher Nielsen)]

libffi: symlink via prev major version

• Absolutely critical, to avoid temporary toolchain breakage

This fix will eliminate future carnage. However, leaving this ticket open; ultimately the toolchain needs to be insulated from our general libffi port.

[mascguy (Christopher Nielsen)]

Folks, my apologies for muddying the waters on this. Per the insights from Josh and Ken, this isn't a big deal: Generally it's a simple matter of ports opportunistically utilizing toolchain components - particularly from cctools - without declaring a proper build dependency. But when the latter is corrected, such as with ffmpeg (issue:63443), there's no longer an issue.

Net-Net, please disregard my previous comments regarding the concern surrounding this: Yours Truly didn't have a complete understanding of the end-to-end details, and I blew this way out of proportion.