Opened 8 years ago

Closed 8 years ago

#40155 closed defect (fixed)

serf1 @1.3.1: Build fails on PPC Tiger (Mac OS X 10.4.11) due to "more than one: -compatibility_version option specified"

Reported by: ballapete (Peter Dyballa) Owned by: blair (Blair Zajac)
Priority: Normal Milestone:
Component: ports Version: 2.2.99
Keywords: tiger Cc: ryandesign (Ryan Schmidt), josephaw@…, marco.comini@…, mp@…
Port: serf1

Description

The failure is here:

/usr/bin/gcc-4.0 -o libserf-1.3.0.0.dylib -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -Wl,-install_name,/opt/local/var/macports/build/_opt_mports_trunk_dports_www_serf1/serf1/work/serf-1.3.1/libserf-1.dylib -Wl,-compatibility_version,4 -Wl,-current_version,4.1 -dynamiclib -current_version 3.0.0 -compatibility_version 3.0.0 -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
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: more than one: -compatibility_version option specified
Usage: /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
scons: *** [libserf-1.3.0.0.dylib] Error 1
scons: building terminated because of errors.
Command failed:  cd "/opt/local/var/macports/build/_opt_mports_trunk_dports_www_serf1/serf1/work/serf-1.3.1" && /opt/local/bin/scons APR=/opt/local APU=/opt/local OPENSSL=/opt/local PREFIX=/opt/local CC=/usr/bin/gcc-4.0 CPPFLAGS="-I/opt/local/include" CFLAGS="-Os -arch ppc" LINKFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc" 
Exit code: 2

Attachments (6)

main.log (28.9 KB) - added by ballapete (Peter Dyballa) 8 years ago.
main.log
patch-tiger.diff (719 bytes) - added by mp@… 8 years ago.
patch to SConstruct to allow build on Tiger
serf1-portfile-40155.diff (929 bytes) - added by mp@… 8 years ago.
Patch to Portfile to allow build on Tiger - corrected
serf1-portfile-40155.2.diff (929 bytes) - added by mp@… 8 years ago.
Patch that should work for all OS X version for scons from 2.3.5
serf1-portfile-40155-possible-fix-for-all-osx-versions.diff (740 bytes) - added by mp@… 8 years ago.
New Portfile patch that uses the scons patch that should work for all OS X versions
patch-sconstruct.diff (649 bytes) - added by mp@… 8 years ago.
Patch that should work for all OS X version for scons from 2.3.5. Really.

Download all attachments as: .zip

Change History (34)

Changed 8 years ago by ballapete (Peter Dyballa)

Attachment: main.log added

main.log

comment:1 Changed 8 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added; blair@… removed
Keywords: tiger added
Owner: changed from macports-tickets@… to blair@…
Summary: Build of serf1 fails on PPC Tiger (Mac OS X 10.4.11) due to "more than one: -compatibility_version option specified"serf1 @1.3.1: Build fails on PPC Tiger (Mac OS X 10.4.11) due to "more than one: -compatibility_version option specified"

comment:2 Changed 8 years ago by josephaw@…

Is there a work around for now? Thanks.

comment:3 Changed 8 years ago by josephaw@…

Cc: josephaw@… added

Cc Me!

comment:4 Changed 8 years ago by blair (Blair Zajac)

No workaround. I started a thread here:

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

Blair

comment:5 Changed 8 years ago by marco.comini@…

Cc: marco.comini@… added

Cc Me!

comment:6 in reply to:  2 ; Changed 8 years ago by ballapete (Peter Dyballa)

Replying to josephaw@…:

Is there a work around for now? Thanks.

I made an experiment by editing line #40 of the Portfile. It now reads

 40                 LINKFLAGS="${configure.ldflags}"

instead of

 40                 LINKFLAGS="${configure.ldflags} [get_canonical_archflags ld]"

before. The only change in the end is that the compiler does not see "-arch ppc". On Leopard the command line to build libserf-1.3.0.0.dylib became:

/usr/bin/gcc-4.2 -o libserf-1.3.0.0.dylib -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-install_name,/opt/local/var/macports/build/_opt_local_var_macports_sources_lil.fr.rsync.macports.org_release_tarballs_ports_www_serf1/serf1/work/serf-1.3.1/libserf-1.dylib -Wl,-compatibility_version,4 -Wl,-current_version,4.1 -dynamiclib -current_version 3.0.0 -compatibility_version 3.0.0 -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
Creating 'serf-1.pc'
scons: done building targets.

I missed to save the previous main.log file, but since I removed subversion, which depends on serf1, I can easily remove serf1 and rebuild it – with a saved log from the *compile* buffer in GNU Emacs for a later comparison…

Last edited 8 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:7 in reply to:  6 ; Changed 8 years ago by ryandesign (Ryan Schmidt)

Replying to Peter_Dyballa@…:

The only change in the end is that the compiler does not see "-arch ppc".

But we want there to be -arch flags.

On Leopard the command line to build libserf-1.3.0.0.dylib became:

This ticket is about build failure on Tiger only; Leopard and later are not affected.

comment:8 in reply to:  7 Changed 8 years ago by ballapete (Peter Dyballa)

Replying to ryandesign@…:

This ticket is about build failure on Tiger only; Leopard and later are not affected.

You're right! I don't see my comment that it's failing on Leopard as well! There must be another package that failed for me on PPC Tiger and on PPC Leopard…

comment:9 Changed 8 years ago by mp@…

Cc: mp@… added

Cc Me!

Changed 8 years ago by mp@…

Attachment: patch-tiger.diff added

patch to SConstruct to allow build on Tiger

comment:10 Changed 8 years ago by mp@…

Added Portfile diff with its SConstruct patch to allow build on Tiger as well.
Works on OS X 10.4.11 (Darwin 8.11.0).
attachment:serf1-portfile-40155.diff
attachment:patch-tiger.diff

Setting env['SHLIBVERSION'] in scons might work also for other versions of OS X.

If someone knows if there is a way to replace only CC in build.args, instead of doing

build.args-append CC=

feel free to let me know how.

Last edited 8 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

Changed 8 years ago by mp@…

Attachment: serf1-portfile-40155.diff added

Patch to Portfile to allow build on Tiger - corrected

comment:11 Changed 8 years ago by mp@…

Noticed an erroneous "\" at the end of a line in the Portfile patch, and although it worked anyway, it is now corrected.

comment:12 Changed 8 years ago by ryandesign (Ryan Schmidt)

Since this patch fixes a build failure, no revision increase is warranted.

Patchfiles that are applied conditionally based on OS version are not ideal, because someone updating the port on a different OS X version will often not notice if and when such a patchfile needs to be updated. Better to write a patch that can be safely applied unconditionally. That's also what's going to be needed to get such a patch accepted upstream.

Why is "build.args-append CC="MACOSX_DEPLOYMENT_TARGET=10.4 ${configure.cc}"" needed? MacPorts automatically sets MACOSX_DEPLOYMENT_TARGET to the major OS X version, in all phases, on all OS X versions.

comment:13 in reply to:  12 Changed 8 years ago by mp@…

Replying to ryandesign@…:

Since this patch fixes a build failure, no revision increase is warranted.

Ah yes, because those systems where it already works don't need to be rebuilt. Thanks.


Patchfiles that are applied conditionally based on OS version are not ideal, because someone updating the port on a different OS X version will often not notice if and when such a patchfile needs to be updated. Better to write a patch that can be safely applied unconditionally. That's also what's going to be needed to get such a patch accepted upstream.

It is possible that the SConstruct patch works for all OS X versions, but I only have Tiger to test on now. The way it's currently handled as a special case for darwin is only to increase the compatibility_version and current_version of the library by one, because OS X wants the major version to start at 1, not 0. Would be nice if someone could try the supplied patch for newer OS X versions.

In other words, it should be possible to replace

  # 'man ld' says positive non-zero for the first number, so we add one.
  # Mac's interpretation of compatibility is the same as our MINOR version.
  env.Append(LINKFLAGS='-Wl,-compatibility_version,%d' % (MINOR+1,))
  env.Append(LINKFLAGS='-Wl,-current_version,%d.%d' % (MINOR+1, PATCH,))

with

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

and let scons take care of it from there for all OS X versions.
I see it's a fairly new feature in scons:

RELEASE 2.3.0 - Mon, 02 Mar 2013 13:22:29 -0400

  • Add SHLIBVERSION as an option that tells SharedLibrary to build
    a versioned shared library and create the required symlinks.

Why is "build.args-append CC="MACOSX_DEPLOYMENT_TARGET=10.4 ${configure.cc}"" needed? MacPorts automatically sets MACOSX_DEPLOYMENT_TARGET to the major OS X version, in all phases, on all OS X versions.

Apparently, this is not recognized by libtool or ld here.
I found #16286, and when building serf1, in the log I can see that it gets set to 10.4:

---> Building serf1
DEBUG: Executing org.macports.build (serf1)
DEBUG: Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_jag_src_macports_ports_www_serf1/serf1/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.4'

DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_jag_src_macports_ports_www_serf1/serf1/work/serf-1.3.1" && /opt/local/bin/scons APR=/opt/local APU=/opt/local OPENSSL=/opt/local PREFIX=/opt/local CC=/usr/bin/gcc-4.0 CPPFLAGS="-I/opt/local/include" CFLAGS="-Os -arch ppc" LINKFLAGS="-L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc"'

but still libtool doesn't seem to get the MACOSX_DEPLOYMENT_TARGET and this causes the linking of libserf to fail:

ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit command failed

That's the reason for the

build.args-append CC="MACOSX_DEPLOYMENT_TARGET=10.4 ${configure.cc}"

Changed 8 years ago by mp@…

Attachment: serf1-portfile-40155.2.diff added

Patch that should work for all OS X version for scons from 2.3.5

Changed 8 years ago by mp@…

New Portfile patch that uses the scons patch that should work for all OS X versions

Changed 8 years ago by mp@…

Attachment: patch-sconstruct.diff added

Patch that should work for all OS X version for scons from 2.3.5. Really.

comment:14 Changed 8 years ago by mp@…

The correct new patches to test on any OS X version – following indications in #comment:12 – are these:

attachment:serf1-portfile-40155-possible-fix-for-all-osx-versions.diff
attachment:patch-sconstruct.diff

Accidentally attached serf1-portfile-40155.2.diff, but that is wrong, and I don't know how to remove it.

Last edited 8 years ago by mp@… (previous) (diff)

comment:15 in reply to:  14 ; Changed 8 years ago by ballapete (Peter Dyballa)

Replying to mp@…:

The correct new patches to test on any OS X version – following indications in #comment:12 – are these:

attachment:serf1-portfile-40155-possible-fix-for-all-osx-versions.diff
attachment:patch-sconstruct.diff

Do I need to patch Portfile, create the files sub-directory, and put the patch files there manually?

comment:16 in reply to:  15 ; Changed 8 years ago by mp@…

Replying to Peter_Dyballa@…:

Do I need to patch Portfile, create the files sub-directory, and put the patch files there manually?

Patch Portfile with attachment:serf1-portfile-40155-possible-fix-for-all-osx-versions.diff ,

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

create files directory, and put attachment:patch-sconstruct.diff in it.

sudo mkdir files
sudo cp ~/Downloads/patch-sconstruct.diff files/

(if they're downoaded in "~/Downloads/", that is...)
The changes will get overwritten by your next port sync or port selfupdate, though, but that shouldn't matter if you have the patched serf1 installed already by then.

Last edited 8 years ago by mp@… (previous) (diff)

comment:17 in reply to:  16 ; Changed 8 years ago by ballapete (Peter Dyballa)

Replying to mp@…:

Replying to Peter_Dyballa@…:

Do I need to patch Portfile, create the files sub-directory, and put the patch files there manually?

Patch Portfile with attachment:serf1-portfile-40155-possible-fix-for-all-osx-versions.diff ,

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

create files directory, and put attachment:patch-sconstruct.diff in it.

sudo mkdir files
sudo cp ~/Downloads/patch-sconstruct.diff files/

(if they're downoaded in "~/Downloads/", that is...)
The changes will get overwritten by your next port sync or port selfupdate, though, but that shouldn't matter if you have the patched serf1 installed already by then.

This worked! It is installed:

  serf1 @1.3.1_0 (active)

comment:18 in reply to:  17 ; Changed 8 years ago by mp@…

Replying to Peter_Dyballa@…:

This worked! It is installed:

  serf1 @1.3.1_0 (active)

Great.
This patch should work for all the system versions, so it would be good if someone with OS X > Tiger could try it too.

comment:19 in reply to:  18 Changed 8 years ago by ballapete (Peter Dyballa)

Replying to mp@…:

Replying to Peter_Dyballa@…: This patch should work for all the system versions, so it would be good if someone with OS X > Tiger could try it too.

I presume that the next few days I'll be busy with gcc48 and related packages on Tiger…

comment:20 Changed 8 years ago by blair (Blair Zajac)

I'll test this out on 10.5 and 10.7 systems. To confirm, only the serf1-portfile-40155-possible-fix-for-all-osx-versions.diff​ and patch-sconstruct.diff​ should be used?

comment:21 in reply to:  20 Changed 8 years ago by mp@…

Replying to blair@…:

I'll test this out on 10.5 and 10.7 systems.

Great.

To confirm, only the serf1-portfile-40155-possible-fix-for-all-osx-versions.diff​ and patch-sconstruct.diff​ should be used?

Correct.

comment:22 Changed 8 years ago by blair (Blair Zajac)

I tried it this morning on my 10.7.5 box and it has a problem that it changes the dylib name. Here's the diff of 'port contents' between the original and this version:

   /opt/local/include/serf-1/serf.h
   /opt/local/include/serf-1/serf_bucket_types.h
   /opt/local/include/serf-1/serf_bucket_util.h
-  /opt/local/lib/libserf-1.3.0.0.dylib
+  /opt/local/lib/libserf-1.4.0.0.dylib
   /opt/local/lib/libserf-1.a
   /opt/local/lib/libserf-1.dylib
   /opt/local/lib/pkgconfig/serf-1.pc

Doing this means recompiling all dependent ports, which I don't want. Do we remove the +1? If so, then what do we do when we get to serf 2.0 that has a minor version of 0? Does the new SHLIBVERSION need to honor the non-zero requirement?

comment:23 Changed 8 years ago by blair (Blair Zajac)

Removing the +1 from the patch changes the internal compatibility, which will still require a recompile of Subversion, since the number is getting smaller.

$ diff -u 1otool 3otool 
--- 1otool	2013-08-31 11:31:59.000000000 -0700
+++ 3otool	2013-08-31 11:42:36.000000000 -0700
@@ -1,5 +1,5 @@
 /opt/local/lib/libserf-1.dylib:
-	/opt/local/lib/libserf-1.3.0.0.dylib (compatibility version 4.0.0, current version 4.1.0)
+	/opt/local/lib/libserf-1.3.0.0.dylib (compatibility version 3.0.0, current version 3.0.0)
 	/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
 	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
 	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8)

The other issue I noticed is that svn has the name of the complete dylib, which it shouldn't. Even after changing the Portfile, bumping serf from 1.3.1 to 1.4.0 would break Subversion, which we cannot have.

$ otool -L /opt/local/bin/svn | grep libserf
	/opt/local/lib/libserf-1.3.0.0.dylib (compatibility version 4.0.0, current version 4.1.0)

So we need to figure out how to get a name like libserf-1.dylib into the programs that link against it.

comment:24 in reply to:  23 Changed 8 years ago by ryandesign (Ryan Schmidt)

Replying to blair@…:

So we need to figure out how to get a name like libserf-1.dylib into the programs that link against it.

That's because of the install_name of libserf-1.3.0.0.dylib.

comment:25 Changed 8 years ago by blair (Blair Zajac)

Thanks, there's code in SConstruct that does this:

if sys.platform == 'darwin':
  # If --install-sandbox=<path> is specified, install_shared_path will point
  # to a path in the sandbox. The shared library install name (id) should be the
  # final targat path.
  install_shared_path = install_shared[0].abspath
  target_install_shared_path = os.path.join(libdir, lib_shared[0].name)
  env.AddPostAction(install_shared, ('install_name_tool -id %s %s'
                                     % (target_install_shared_path,
                                        install_shared_path)))

Until this code gets fixed, I won't roll out a serf1 update, don't want to do two recompiles of dependent ports.

comment:26 Changed 8 years ago by ryandesign (Ryan Schmidt)

The problem is that the build system uses more than one -compatibility_version option. The old libtool on Tiger complains about this. The new libtool on newer OS X silently ignores one of them. The fix should be to remove the duplicate option that's not being used.

That doesn't appear to be what the patch attached to this ticket does. The patch seems to remove the -compatibility_version option that's actually relevant, causing the build to then fall back on the option that was previously being ignored, which has the wrong values, which cause all the issues you mentioned above. So that's not what we want.

The problem is that I only see one occurrence of -compatibility_version in the source, in the SConstruct, and that's the one we want to use. Where is the one we don't want to use coming from? Is scons inserting that itself? If so we need to figure out how to suppress that or tell it to use the values we want instead of the wrong values it thinks we want.

comment:27 in reply to:  26 Changed 8 years ago by mp@…

Replying to ryandesign@…:

The problem is that the build system uses more than one -compatibility_version option. The old libtool on Tiger complains about this. The new libtool on newer OS X silently ignores one of them. The fix should be to remove the duplicate option that's not being used.

Removing the duplicate option is exactly what this patch does, letting scons take care of it.

That doesn't appear to be what the patch attached to this ticket does. The patch seems to remove the -compatibility_version option that's actually relevant, causing the build to then fall back on the option that was previously being ignored, which has the wrong values, which cause all the issues you mentioned above. So that's not what we want.

No, it sets SHLIBVERSION to the correct value (MINOR+1).

The problem is that I only see one occurrence of -compatibility_version in the source, in the SConstruct, and that's the one we want to use. Where is the one we don't want to use coming from? Is scons inserting that itself? If so we need to figure out how to suppress that or tell it to use the values we want instead of the wrong values it thinks we want.

Basically, the idea with this patch is to allow scons to handle the -compatibility/current_version by setting

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

so that it's not set twice.
A more thorough explanation is in comment:13.

It works correctly on 10.4, and according to comment:22 also on 10.7. (The libversion increase mentioned comment:22 might be because SHLIBVERSION was set to 3.0.0 and the -compatibility/current_version to 4.0.0, apparently causing the 3.0.0 to be used. I don't have 10.7 to confirm this cause, so it's just a theory.)

comment:28 Changed 8 years ago by blair (Blair Zajac)

Resolution: fixed
Status: newclosed

Fixed in r110506 and r110508

Note: See TracTickets for help on using tickets.