Opened 11 years ago
Closed 11 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 "Pete" Dyballa) | Owned by: | blair (Blair Zajac) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.2.99 |
Keywords: | tiger | Cc: | ryandesign (Ryan Carsten 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)
Change History (34)
Changed 11 years ago by ballapete (Peter "Pete" Dyballa)
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten 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:4 Changed 11 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:6 follow-up: 7 Changed 11 years ago by ballapete (Peter "Pete" 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…
comment:7 follow-up: 8 Changed 11 years ago by ryandesign (Ryan Carsten 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 Changed 11 years ago by ballapete (Peter "Pete" 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…
Changed 11 years ago by mp@…
Attachment: | patch-tiger.diff added |
---|
patch to SConstruct to allow build on Tiger
comment:10 Changed 11 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.
Changed 11 years ago by mp@…
Attachment: | serf1-portfile-40155.diff added |
---|
Patch to Portfile to allow build on Tiger - corrected
comment:11 Changed 11 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 follow-up: 13 Changed 11 years ago by ryandesign (Ryan Carsten 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 Changed 11 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 11 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 11 years ago by mp@…
Attachment: | serf1-portfile-40155-possible-fix-for-all-osx-versions.diff added |
---|
New Portfile patch that uses the scons patch that should work for all OS X versions
Changed 11 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 follow-up: 15 Changed 11 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.
comment:15 follow-up: 16 Changed 11 years ago by ballapete (Peter "Pete" 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 follow-up: 17 Changed 11 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.
comment:17 follow-up: 18 Changed 11 years ago by ballapete (Peter "Pete" 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.diffcreate 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 nextport sync
orport selfupdate
, though, but that shouldn't matter if you have the patchedserf1
installed already by then.
This worked! It is installed:
serf1 @1.3.1_0 (active)
comment:18 follow-up: 19 Changed 11 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 Changed 11 years ago by ballapete (Peter "Pete" 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 follow-up: 21 Changed 11 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 Changed 11 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 11 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 follow-up: 24 Changed 11 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 Changed 11 years ago by ryandesign (Ryan Carsten 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 11 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 follow-up: 27 Changed 11 years ago by ryandesign (Ryan Carsten 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 Changed 11 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 11 years ago by blair (Blair Zajac)
Resolution: | → fixed |
---|---|
Status: | new → closed |
main.log