[MacPorts] #69380: libffi fails on 10.5 PPC for bad patch

MacPorts noreply at macports.org
Tue Feb 27 16:22:15 UTC 2024


#69380: libffi fails on 10.5 PPC for bad patch
-----------------------+-------------------------
  Reporter:  rmottola  |      Owner:  (none)
      Type:  defect    |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:  leopard ppc
      Port:  libffi    |
-----------------------+-------------------------

Comment (by ballapete):

 Replying to [comment:24 rmottola]:

 > Said that, I see several kinds of warnings in the tessuite log:
 >
 >
 > {{{
 > ../../testsuite/libffi.bhaible/test-call.c:35: warning: unused parameter
 �~@~Xstream�~@~Y^M
 > ../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter
 �~@~Xa�~@~Y^M
 > ../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter
 �~@~Xb�~@~Y^M
 > ../../testsuite/libffi.bhaible/test-call.c:87: warning: unused parameter
 �~@~Xc�~@~Y^M
 > }}}
 > ... (repeated for dozens of lines)
 >
 This is in my opinion harmless. It's just a warning, and the strange text
 comes from different multi-byte character encodings in some file and in
 your terminal application and no means were taken to re-encode the file's
 contents for display use.

 > but also this which looks worse:
 >
 > {{{
 > ld warning: in
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/i386
 -apple-darwin9.8.0/.libs/libffi.dylib, file is not of required
 architecture^M
 > Undefined symbols:^M

 That's a real failure. Maybe it helps to build, install, test `libffi
 +universal`. This might produce "fat" libraries with 32-bit and 64-bit
 versions in one library file. OTOH, the question is, why is some test
 routine assuming a 64 bit architecture, i.e. x86_64-apple-darwin9.8.0? As
 far as I understand `libffi` a `configure` script determines the
 underlying architecture and records it in files and directory names. So
 there should not exist  either a need or a cause to switch the
 architectures…

 There is a small utility, `file`, that can determine which kind a "file"
 is (and in UNIX everything is assumed to be a file in some file system).
 Its usage would be:

 {{{
 file
 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libffi/libffi/work/libffi-3.4.6/i386
 -apple-darwin9.8.0/.libs/libffi.dylib
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/69380#comment:25>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list