[MacPorts] #58748: libproj4: object: libproj4.a(proj_aeqd.o) malformed object (unknown load command 1) (was: MacPorts 2.5.4: Failed to build libproj4 when installing gnudatalanguage)

[MacPorts]

#58748: libproj4: object: libproj4.a(proj_aeqd.o) malformed object (unknown load
command 1)
------------------------+--------------------
  Reporter:  lchuang52  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:
Resolution:             |   Keywords:
      Port:  libproj4   |
------------------------+--------------------
Changes (by ryandesign):

 * port:   => libproj4


Old description:

> Hi! I am installing gnudatalanguage, but I meet this problem:
>
> --->  Building libproj4
> Error: Failed to build libproj4: command execution failed
> Error: See
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_libproj4/libproj4/main.log
> for details.
> Error: Follow https://guide.macports.org/#project.tickets to report a
> bug.
> Error: Processing of port gnudatalanguage failed

New description:

 Hi! I am installing gnudatalanguage, but I meet this problem:

 {{{
 --->  Building libproj4
 Error: Failed to build libproj4: command execution failed
 Error: See
 /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gis_libproj4/libproj4/main.log
 for details.
 Error: Follow https://guide.macports.org/#project.tickets to report a bug.
 Error: Processing of port gnudatalanguage failed
 }}}

--

Comment:

 This problem does not seem to me to be specific to the libproj4 port,
 since the libproj4 port does not specify or require a particular compiler;
 I expect you will encounter similar problems with other ports.

 The log says:

 {{{
 :debug:configure Preferred compilers: cc
 :debug:configure Using compiler 'System cc'
 }}}

 {{{
 :info:build /usr/bin/cc -I. -I/opt/local/include -DPROJ_HAVE_GSL=1
 -DPROJ_HAVE_THREADS=1 -Os -m64   -c -o proj_aeqd.o proj_aeqd.c
 }}}

 This is surprising. "System cc" is a fallback included in MacPorts
 primarily for the virtually completely unused use case of MacPorts running
 on non-macOS systems. When running on macOS systems, MacPorts should be
 picking a more specific compiler, such as Xcode's clang. You should only
 see this behavior on macOS if you have installed neither Xcode nor the
 command line tools. And the log shows that, at least as far as MacPorts
 knows, that is the case:

 {{{
 :debug:sysinfo Xcode none
 }}}

 I see from the log that you're using macOS Mojave. To use MacPorts on
 Mojave, we recommend installing Xcode. Make sure you install a version of
 Xcode compatible with Mojave (Xcode 10 or 11). If you have installed the
 command line tools, make sure it is a version that matches the version of
 Xcode you have installed.

 The log also shows:

 {{{
 :info:build ar rv libproj4.a proj_aeqd.o
 :info:build ar: creating archive libproj4.a
 :info:build /opt/local/bin/ranlib: object: libproj4.a(proj_aeqd.o)
 malformed object (unknown load command 1)
 :info:build ar: internal ranlib command failed
 }}}

 `ar` and `ranlib` are provided by the cctools port. This error message
 suggests that your cctools is too old to understand the files being
 produced by whatever compiler is being used. The cctools port currently
 provides version 921, which matches what Apple shipped in Xcode 10. If you
 are using the clang compiler from Xcode 11, then you need a newer version
 of cctools than that. I have [ticket:58749 requested] that the cctools
 port be updated to an Xcode 11-compatible version, but until that's done,
 you'll need to reinstall the cctools port with the +xcode variant.

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