Subversion 1.6.x fails to upgrade on Tiger when 1.5.x is installed

[vinc17@…]

"sudo port -v upgrade subversion" gives the following error:

/bin/sh /opt/local/var/macports/build/_Users_vinc17_software_dports_devel_subversion/work/subversion-1.6.0/libtool --tag=CC --silent --mode=compile /usr/bin/gcc-4.0 -I/opt/local/include   -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp  -I/opt/local/include/apr-1   -I/opt/local/include/apr-1 -I/opt/local/include  -O2     -I./subversion/include -I./subversion -I/opt/local/include/apr-1   -I/opt/local/include/apr-1 -I/opt/local/include -I/opt/local/include/neon -I/opt/local/include -I/opt/local/include/serf-0  -o subversion/libsvn_fs_fs/tree.lo -c subversion/libsvn_fs_fs/tree.c
/bin/sh /opt/local/var/macports/build/_Users_vinc17_software_dports_devel_subversion/work/subversion-1.6.0/libtool --tag=CC --silent --mode=compile /usr/bin/gcc-4.0 -I/opt/local/include   -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp  -I/opt/local/include/apr-1   -I/opt/local/include/apr-1 -I/opt/local/include  -O2     -I./subversion/include -I./subversion -I/opt/local/include/apr-1   -I/opt/local/include/apr-1 -I/opt/local/include -I/opt/local/include/neon -I/opt/local/include -I/opt/local/include/serf-0  -o subversion/libsvn_fs_util/fs-util.lo -c subversion/libsvn_fs_util/fs-util.c
cd subversion/libsvn_fs_util && /bin/sh /opt/local/var/macports/build/_Users_vinc17_software_dports_devel_subversion/work/subversion-1.6.0/libtool --tag=CC --silent --mode=link /usr/bin/gcc-4.0  -O2     -L/opt/local/lib    -L/opt/local/lib/db46 -L/opt/local/lib -L/opt/local/lib  -rpath /opt/local/lib -o libsvn_fs_util-1.la  fs-util.lo ../../subversion/libsvn_subr/libsvn_subr-1.la /opt/local/lib/libaprutil-1.la  -ldb-4.6 -lexpat -liconv /opt/local/lib/libapr-1.la -lpthread -lintl  -framework Security -framework CoreFoundation -framework CoreServices
ERROR: No debug map or DWARF data was found to link.cd subversion/libsvn_fs_fs && /bin/sh /opt/local/var/macports/build/_Users_vinc17_software_dports_devel_subversion/work/subversion-1.6.0/libtool --tag=CC --silent --mode=link /usr/bin/gcc-4.0  -O2     -L/opt/local/lib    -L/opt/local/lib/db46 -L/opt/local/lib -L/opt/local/lib  -rpath /opt/local/lib -o libsvn_fs_fs-1.la  caching.lo dag.lo err.lo fs.lo fs_fs.lo id.lo key-gen.lo lock.lo rep-cache.lo tree.lo ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /opt/local/lib/libaprutil-1.la  -ldb-4.6 -lexpat -liconv /opt/local/lib/libapr-1.la -lpthread ../../subversion/libsvn_fs_util/libsvn_fs_util-1.la -lintl  -framework Security -framework CoreFoundation -framework CoreServices
ld: Undefined symbols:
_svn_error__malfunction referenced from libsvn expected to be defined in libsvn
_svn_checksum_ctx_create referenced from libsvn expected to be defined in libsvn
_svn_checksum_final referenced from libsvn expected to be defined in libsvn
_svn_checksum_update referenced from libsvn expected to be defined in libsvn
/usr/bin/libtool: internal link edit command failed
make: *** [subversion/libsvn_fs_fs/libsvn_fs_fs-1.la] Error 1

[vinc17@…]

If subversion is not activated during the upgrade, then just bug #18921 occurs.

[steven@…]

Cc Me!

[erks@…]

This seems to happen only on Tiger. I do not experience this problem on Leopard (only bug #18921, which is fixed).

[erks@…]

Uninstall/deactivate the old subversion port and reinstall the new one seems to work, though. Only when doing 'port upgrade' that this problem arises.

[danielluke (Daniel J. Luke)]

Since I don't have a tiger system to test on, can someone upload the full build log (and/or a patch to fix the issue ;-) ).

Thanks.

[vinc17@…]

build log

[vinc17@…]

BTW, concerning the line

cd subversion/libsvn_fs_fs && /bin/sh /opt/local/var/macports/build/_Users_vinc17_software_dports_devel_subversion/work/subversion-1.6.0/libtool --tag=CC --silent --mode=link /usr/bin/gcc-4.0  -O2     -L/opt/local/lib    -L/opt/local/lib/db46 -L/opt/local/lib -L/opt/local/lib  -rpath /opt/local/lib -o libsvn_fs_fs-1.la  caching.lo dag.lo err.lo fs.lo fs_fs.lo id.lo key-gen.lo lock.lo rep-cache.lo tree.lo ../../subversion/libsvn_delta/libsvn_delta-1.la ../../subversion/libsvn_subr/libsvn_subr-1.la /opt/local/lib/libaprutil-1.la  -ldb-4.6 -lexpat -liconv /opt/local/lib/libapr-1.la -lpthread ../../subversion/libsvn_fs_util/libsvn_fs_util-1.la -lintl  -framework Security -framework CoreFoundation -framework CoreServices

I don't see where libsvn is referenced. So I wonder why one gets the following error:

ld: Undefined symbols:
_svn_error__malfunction referenced from libsvn expected to be defined in libsvn
_svn_checksum_ctx_create referenced from libsvn expected to be defined in libsvn
_svn_checksum_final referenced from libsvn expected to be defined in libsvn
_svn_checksum_update referenced from libsvn expected to be defined in libsvn
/usr/bin/libtool: internal link edit command failed

[(none)]

Milestone Port Bugs deleted

[vinc17@…]

Still occurs with Subversion 1.6.1.

What's strange is if I build Subversion manually, with the same configure command (the one that is written in the generated config.log file), I got no errors. Does MacPorts do anything special?

[danielluke (Daniel J. Luke)]

Replying to vinc17@…:

Still occurs with Subversion 1.6.1.

What's strange is if I build Subversion manually, with the same configure command (the one that is written in the generated config.log file), I got no errors. Does MacPorts do anything special?

Well, the problem is that the build is picking up the installed subversion libs. MacPorts by default searches ${prefix} (/opt/local), so if you have an old subversion installed by macports, but then build outside of it, it won't see the MacPorts installed libs unless you point the build process to them, so you won't see the issue.

[vinc17@…]

Replying to dluke@…:

Well, the problem is that the build is picking up the installed subversion libs. MacPorts by default searches ${prefix} (/opt/local),

I do that too when building Subversion manually, and I don't get a failure. So, this should not be a problem. The problem may be due to the fact that MacPorts defines LDFLAGS (and CPPFLAGS); this is probably a bug. I'll do some more tests...

[vinc17@…]

No, LDFLAGS and CPPFLAGS were not the problem.

[vinc17@…]

The bug occurs when the MACOSX_DEPLOYMENT_TARGET environment variable is "10.4".

[ctempleton3@…]

Cc Me!

[cgtobi@…]

Cc Me!

[vinc17@…]

Adding

macosx_deployment_target 10.1

fixes the bug on my machine. But I don't know whether it must be done conditionally (e.g. on Tiger) or not.

[vinc17@…]

patch that fixes the bug on Tiger

[vinc17@…]

This bug has been open for quite a long time. I've added a patch that implements the solution I proposed above, which works on my machine under 10.4.11 (but I don't know what this is supposed to do in general and the consequences with other Mac OS X versions).

[danielluke (Daniel J. Luke)]

As Tiger is no longer one of the 'supported' versions, I'm going to close this ticket.

I'm happy to add a patch for this, if someone else can generate it and test it.

In the meantime, if you're using Tiger, you can work-around the problem fairly simply.

[vinc17@…]

Replying to dluke@…:

As Tiger is no longer one of the 'supported' versions, I'm going to close this ticket.

When there are Tiger users who still propose patches, you shouldn't close the ticket.

I'm happy to add a patch for this, if someone else can generate it and test it.

The patch (see Portfile.diff) fixes the problem on Tiger. All what you need to do is to find someone who has Leopard (that shouldn't be too difficult to find...) and can test the patch to see if it doesn't make the build fail on Leopard. If everything is fine, then commit the patch. Otherwise one needs to set macosx_deployment_target only if the system is Tiger.

[vinc17@…]

I've updated the summary to make it more accurate (1.5.x should no longer be installed, but the bug may become visible again in the 1.6.x -> 1.7.x upgrade).

[danielluke (Daniel J. Luke)]

Do you know why that patch works? I think it's just a side effect of the 10.1 compilation environment, and it probably has other (not desired) effects as well.

I will not be applying this patch, if someone wants to create one that fixes the build I would consider adding it to the port.

In the meanwhile, anyone who experiences this problem has a simple and effective workaround already.

[vinc17@…]

Replying to dluke@…:

Do you know why that patch works?

IIRC, because Subversion's configure file does something bad when MACOSX_DEPLOYMENT_TARGET is 10.4 (FYI that's how I found that switching to 10.1 solved the problem).

I think it's just a side effect of the 10.1 compilation environment, and it probably has other (not desired) effects as well.

Do you mean that the 10.1 compilation environment is also installed on Tiger?

I've used this for months and haven't seen any problem.

I will not be applying this patch, if someone wants to create one that fixes the build I would consider adding it to the port.

I'll try to build another patch (which would be more complex).

[vinc17@…]

configure patch

[vinc17@…]

Add the file patch-configure.diff in the files directory and add patch-configure.diff to patchfiles.

I've tested the upgrade from subversion @1.5.6_0+tools to subversion @1.6.5_0+tools (with this configure patch) on Tiger, and got no errors. Subversion works fine.

This configure patch has the effect to use

-flat_namespace -undefined suppress

instead of

-undefined dynamic_lookup

under Tiger (I've done the change for Tiger only; thus Leopard should not be affected).

[danielluke (Daniel J. Luke)]

-flat_namespace is also not a very good solution as it ends up with the potential of having namespace pollution problems.

Since this only effects the upgrade, and there's a simple workaround for the build problem, I'm not willing to commit patches that have a reasonable probability of causing other problems.

[blb@…]

Wouldn't the simplest and cleanest fix be to make sure the -I and -L flags for the build-time items appear before -I${prefix}/include and -L${prefix}/lib?

[danielluke (Daniel J. Luke)]

Replying to blb@…:

Wouldn't the simplest and cleanest fix be to make sure the -I and -L flags for the build-time items appear before -I${prefix}/include and -L${prefix}/lib?

That works for me, if it works (I don't have a Tiger machine to test on).

[vinc17@…]

Replying to blb@…:

Wouldn't the simplest and cleanest fix be to make sure the -I and -L flags for the build-time items appear before -I${prefix}/include and -L${prefix}/lib?

No, the problem is not due to these options, which are fine, but to "-rpath /opt/local/lib". If I remove this from Makefile, the failure disappears. That's strange that -rpath is used because I've never seen it necessary under Mac OS X. Moreover this option is not documented. So, I'd say that the solution is to remove "-rpath $(libdir)" from the Makefile (if this works).

[vinc17@…]

Hmm... the -rpath here is in fact a libtool option. But it may be broken.

[arto.bendiken@…]

Just wanted to report that I experienced this problem on a Tiger machine, and was able to solve it simply by deactivating the previously-installed SVN version per vinc17's comment.

[vinc17@…]

Replying to arto.bendiken@…:

Just wanted to report that I experienced this problem on a Tiger machine, and was able to solve it simply by deactivating the previously-installed SVN version per vinc17's comment.

You did not solve the problem. You just found a workaround. The bug is in Subversion, which uses an obsolete libtool version (1.5.26), so with no chance to have any bug fixed there. IIRC I tried to build Subversion with libtool 2.x, without success.

[vinc17@…]

First, this is not a Tiger bug, but a known libtool 1.5.x bug. Debian has the same problem (if I understand correctly -- this was mentioned in the Subversion dev list):

​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291641

Perhaps Apple introduced some workaround for some non-Tiger machines (or a bug that makes the libtool bug disappear).

The same bug was reported as #27618 by someone else and this one is still open...