serf1: building error on OSX 10.4 Server (PPC)

[macports-trac@…]

While building nmap dependencies:

Error: Failed to install serf1 ...
Error: The following dependencies were not installed: subversion serf1 ...
Error: Processing of port nmap failed

Mac OS X Server 10.4.11 PowerPC G5 MacPorts 2.3.0 MacPorts Apple GCC 4.2

[mf2k (Frank Schima)]

In the future, please use WikiFormatting, fill in the Port field and Cc the port maintainers (port info --maintainers serf1).

[blair (Blair Zajac)]

It looks like serf1's cmake isn't designed to support 10.4 as this is the error:

:info:build MACOSX_DEPLOYMENT_TARGET=10.4 /opt/local/bin/gcc-apple-4.2 -o libserf-1.1.3.4.dylib -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -Wl,-install_name,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_www_serf1/serf1/work/serf-1.3.4/libserf-1.dylib -dynamiclib -current_version 1.3.4 -compatibility_version 1.3.4 -undefined dynamic_lookup context.os incoming.os outgoing.os ssltunnel.os buckets/aggregate_buckets.os buckets/allocator.os buckets/barrier_buckets.os buckets/buckets.os buckets/bwtp_buckets.os buckets/chunk_buckets.os buckets/dechunk_buckets.os buckets/deflate_buckets.os buckets/file_buckets.os buckets/headers_buckets.os buckets/iovec_buckets.os buckets/limit_buckets.os buckets/mmap_buckets.os buckets/request_buckets.os buckets/response_body_buckets.os buckets/response_buckets.os buckets/simple_buckets.os buckets/socket_buckets.os buckets/ssl_buckets.os auth/auth.os auth/auth_basic.os auth/auth_digest.os auth/auth_spnego.os auth/auth_spnego_gss.os auth/auth_spnego_sspi.os -L/opt/local/lib -L/opt/local/lib/db46 -L/opt/local/lib -lssl -lcrypto -lz -lapr-1 -lpthread -laprutil-1 -ldb-4.6 -lexpat -liconv
158	:info:build /usr/bin/ld: -i argument: nstall_name must have a ':' between its symbol names

I don't have 10.4 nor even if I did have time to look at it, so if you want to supply a patch that fixes the build on your OS, I would take it.

Alternatively, you could ask the developers on the serf mailing list for a suggestion:

​https://groups.google.com/forum/#!forum/serf-dev

Blair

[macports-trac@…]

Replying to blair@…:

Error seems to be connected with scons:

:info:build scons: `libserf-1.a' is up to date.
:info:build MACOSX_DEPLOYMENT_TARGET=10.4 /opt/local/bin/gcc-apple-4.2 -o libserf-1.1.3.4.dylib ...
...
:info:build scons: *** [libserf-1.1.3.4.dylib] File exists
:info:build scons: building terminated because of errors.

This looks very similar to ​https://trac.macports.org/ticket/40155:

scons: *** [libserf-1.3.0.0.dylib] Error 1
scons: building terminated because of errors.

With that ticket 40155 is a patch attachment to be installed by:

cd /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/www/serf1/
sudo patch <~/Downloads/serf1-portfile-40155-possible-fix-for-all-osx-versions.diff

That patch still works on the Portfile, but the included patch for the python file SConstruct in ...work/serf-1.3.4 is rejected.

That patch deleted two 'env.Append(LINKFLAGS='-Wl,...' lines that no longer exist in serf-1.3.4. It also inserted one new line:

env['SHLIBVERSION']='${%d}.0.0' % (MINOR+1,)

After 1) port sync, 2) port clean serf1, 3) port install serf1, I manually patched this line into SConstruct. This did change the error message to:

:info:build scons: *** [libserf-1.4.0.0.dylib] File exists
:info:build scons: building terminated because of errors.

When I directly change to the version used in Ticket 40155:

env['SHLIBVERSION']='3.0.0'

The result is:

:info:build scons: *** [libserf-1.3.0.0.dylib] File exists
:info:build scons: building terminated because of errors.

Strangely – none of these shared google libraries "libserf-1.x.x.x.dylib" actually "exist" in /opt/local/lib/.

Axel

[cooljeanius (Eric Gallager)]

Cc Me!

[djlambe11@…]

My apologies if I'm going about this the wrong way; this is my first contribution to the MacPorts project.

I've attached a modified patch-SConstruct.diff that enables the build to complete on OS X 10.4.

The problem appears to be passing -Wl,-install_name -- from the ld man page:

...
-dylib_install_name name
        For dynamic shared library files, specifies the name of the file
        the library will be installed in for programs that use  it.   If
        this  is not specified, the name specified in the -o name option
        will  be  used.   This  option  is  used   as   the   libtool(1)
        -install_name name option when its -dynamic option is specified.
...

So the diff I attached changes -Wl,-install_name to -Wl,-dylib_install_name, on top of the changes applied by the original patch.

[rmottola (Riccardo)]

have you tried forcing a macports compiler? at least gcc 4.8, better gcc 6, for example