apr uses paths from old coreutils +with_default_names

[wp@…]

The log :

:info:build /opt/local/share/apr-1/build/libtool: line 819: /opt/local/bin/echo: No such file or directory
:info:build /opt/local/share/apr-1/build/libtool: line 821: /opt/local/bin/echo: No such file or directory
:info:build /opt/local/share/apr-1/build/libtool: line 819: /opt/local/bin/echo: No such file or directory
:info:build /opt/local/share/apr-1/build/libtool: line 755: /opt/local/bin/echo: No such file or directory
:info:build /opt/local/share/apr-1/build/libtool: line 821: /opt/local/bin/echo: No such file or directory
:info:build make: *** [buckets/request_buckets.lo] Error 1
:info:build make: *** Waiting for unfinished jobs....
:info:build /opt/local/share/apr-1/build/libtool: line 755: /opt/local/bin/echo: No such file or directory
:info:build make: *** [buckets/aggregate_buckets.lo] Error 1
:info:build shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/work/serf-0.7.0" && /usr/bin/make -j2 all " returned error 2
:error:build Target org.macports.build returned: shell command failed (see log for details)
:debug:build Backtrace: shell command failed (see log for details)
    while executing
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: the following items did not execute (for serf): org.macports.activate org.macports.build org.macports.destroot org.macports.install
:notice:build Log for serf is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf/main.log

the fix :

sudo ln -s /opt/local/libexec/gnubin/echo /opt/local/bin

[blair@…]

Doing a symlink is not the proper fix.

Please uninstall and install your apr to pick up the change in coreutils in that ${prefix}/bin/echo is no longer provided in that location.

Daniel, we probably need to bump apr's revision to handle people that had coreutils +with_default_names installed. I'm looking at my own install and it has this:

# An echo program that does not interpret backslashes.
ECHO="/opt/local/bin/echo"

[dluke@…]

+with_default_names was always a bad idea and isn't in the current port (which is probably why the reporter is seeing a problem as they had +with_default_names installed in the past, and now the utils are just in gnubin).

It looks like setting lt_ECHO to just 'echo' doesn't work - but setting it to /bin/echo does.

I committed an update in r73724. I don't think the port needs a revbump unless we get a sense that this affects a large number of people (to avoid everyone who doesn't have coreutils +with_default_names rebuilding apr for no reason).

[robin@…]

I've just done a full port upgrade and I'm seeing this error, I'll try the other fixes but wanted to mention it here as 3 months have gone by so I would assume that the fix would have worked its way through by now but hasn't for me.

I've nothing special in terms of configuration and no idea what +with_default_names is so it is set to whatever the default value is.

[dluke@…]

You're seeing this exact error?

 /opt/local/bin/echo: No such file or directory

If so, please attach a full build log.

If not, you will want to create a new ticket, as you're experiencing a different issue.

If you're having this issue (from coreutils +with_default_names), you can (probably) fix it by uninstalling and reinstalling apr (after updating coreutils to a version that doesn't have +with_default_names or after uninstalling or deactivating coreutils).