serf1 build failed: install_name_tool: malformed object (unknown load command 4)

[macports.org@…]

I want to try codeblocks, so while doing a "port install codeblocks", the installation of the dependency serf1 fails.

The relevant lines from the log:

:info:destroot scons: Building targets ...
:info:destroot Install file: "libserf-1.a" as "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.a"
:info:destroot Install file: "libserf-1.1.3.4.dylib" as "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib"
:info:destroot install_name_tool -id /opt/local/lib/libserf-1.dylib /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib
:info:destroot install_name_tool: for architecture x86_64 object: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib malformed object (unknown load command 4)
:info:destroot scons: *** [/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib] Error 1
:info:destroot scons: building terminated because of errors.
:info:destroot Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/serf-1.3.4" && /opt/local/bin/scons install --install-sandbox=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot 
:info:destroot Exit code: 2
:error:destroot org.macports.destroot for port serf1 returned: command execution failed
:debug:destroot Error code: CHILDSTATUS 38771 2
:debug:destroot Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec destroot"
    (procedure "portdestroot::destroot_main" line 2)
    invoked from within
"$procedure $targetname"
:info:destroot Warning: targets not executed for serf1: org.macports.install org.macports.destroot

[ryandesign (Ryan Carsten Schmidt)]

Replying to macports.org@…:

:info:destroot install_name_tool: for architecture x86_64 object: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/destroot/opt/local/lib/libserf-1.1.3.4.dylib malformed object (unknown load command 4)

This means that your install_name_tool command is too old for your version of OS X. To fix this, (re)install the latest version of the Xcode command line tools designed for your OS X version.

[macports.org@…]

Wouldn't it help to decrease the number of invalid tickets, if the port system would check the binaries as configure-scripts do that?

I have fallen twice now for avoidable tickets (I admit it and go to my corner to shame myself), both connected to me changing back and forth between old laptop and new work machine (including different OS) not remembering state of the installed software base, and twice I got reminded "this is obvious for a developer", but it isn't for me. I read log files if the installation points me to it, but I can't draw the line to "obvious", especially when hidden deep in a dependency, deep in a backtrace on a late stage of the build.

I wouldn't expect an obvious error to happen that late. That's why I started writing tickets, otherwise I would have gotten the reinstallation route much earlier, and saved your time.

[ryandesign (Ryan Carsten Schmidt)]

Replying to macports.org@…:

Wouldn't it help to decrease the number of invalid tickets, if the port system would check the binaries as configure-scripts do that?

What, specifically, are you suggesting we have MacPorts do in this case? Check, every time MacPorts runs, that install_name_tool is the correct version for the current version of OS X? That would require at minimum that we be able to determine the current version of install_name_tool, and then maintain a list of acceptable version numbers for each version of OS X. And as far as I can tell, the install_name_tool command does not accept a --version or -v argument so I don't know how to determine its version. Anyway, the command line tools comprises thousands of files; we couldn't be expected to know the correct versions of and check the versions of each of them every time MacPorts runs.

We require users to install versions of MacPorts and Xcode and the Xcode command line tools appropriate for the current version of OS X. This is amply documented.

At the time you install MacPorts, it's supposed to verify that Xcode and the command line tools are installed, but Mavericks changed the way the command line tools work, so our check for whether the command line tools were installed no longer detected the case where they were not. I believe this has been fixed for the upcoming MacPorts 2.3. See r115900.

I was considering writing a ProblemHotlist entry for the "unknown load command" error since I've seen several tickets for it over the years, and I have now done so: ProblemHotlist#malformed-object

[neverpanic (Clemens Lang)]

We could check the version of the Command Line Tools and warn users if there's a newer version available. Of course that means encouraging everybody to use the latest release, which we currently do not.