Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#18937 closed defect (wontfix)

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

Reported by: vinc17@… Owned by: danielluke (Daniel J. Luke)
Priority: Normal Milestone:
Component: ports Version: 1.7.0
Keywords: Cc: steven@…, ctempleton3@…, cgtobi@…
Port: subversion

Description

"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

Attachments (3)

subversion.out.bz2 (5.0 KB) - added by vinc17@… 10 years ago.
build log
Portfile.diff (531 bytes) - added by vinc17@… 10 years ago.
patch that fixes the bug on Tiger
patch-configure.diff (1.5 KB) - added by vinc17@… 10 years ago.
configure patch

Download all attachments as: .zip

Change History (35)

comment:1 Changed 10 years ago by vinc17@…

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

comment:2 Changed 10 years ago by steven@…

Cc: steven@… added

Cc Me!

comment:3 Changed 10 years ago by erks@…

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

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by danielluke (Daniel J. Luke)

Owner: changed from dluke@… to dluke@…
Status: newassigned

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.

Changed 10 years ago by vinc17@…

Attachment: subversion.out.bz2 added

build log

comment:6 Changed 10 years ago by 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

comment:7 Changed 10 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

comment:8 Changed 10 years ago by vinc17@…

Summary: Subversion 1.6.0 fails to buildSubversion 1.6.x fails to build

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?

comment:9 in reply to:  8 ; Changed 10 years ago by 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.

comment:10 in reply to:  9 Changed 10 years ago by 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...

comment:11 Changed 10 years ago by vinc17@…

No, LDFLAGS and CPPFLAGS were not the problem.

comment:12 Changed 10 years ago by vinc17@…

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

comment:13 Changed 10 years ago by ctempleton3@…

Cc: ctempleton3@… added

Cc Me!

comment:14 Changed 10 years ago by tobypeterson

Summary: Subversion 1.6.x fails to buildSubversion 1.6.x fails to build on Tiger

comment:15 Changed 10 years ago by cgtobi@…

Cc: cgtobi@… added

Cc Me!

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by danielluke (Daniel J. Luke)

Summary: Subversion 1.6.x fails to build on TigerSubversion 1.6.x fails to upgrade on Tiger when previous version is installed

Changed 10 years ago by vinc17@…

Attachment: Portfile.diff added

patch that fixes the bug on Tiger

comment:18 Changed 10 years ago by 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).

comment:19 Changed 10 years ago by danielluke (Daniel J. Luke)

Resolution: wontfix
Status: assignedclosed

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.

comment:20 in reply to:  19 Changed 10 years ago by vinc17@…

Resolution: wontfix
Status: closedreopened

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.

comment:21 Changed 10 years ago by vinc17@…

Summary: Subversion 1.6.x fails to upgrade on Tiger when previous version is installedSubversion 1.6.x fails to upgrade on Tiger when 1.5.x is installed

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).

comment:22 Changed 10 years ago by danielluke (Daniel J. Luke)

Resolution: wontfix
Status: reopenedclosed

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.

comment:23 in reply to:  22 Changed 10 years ago by 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).

Changed 10 years ago by vinc17@…

Attachment: patch-configure.diff added

configure patch

comment:24 Changed 10 years ago by vinc17@…

Resolution: wontfix
Status: closedreopened

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).

comment:25 Changed 10 years ago by danielluke (Daniel J. Luke)

Resolution: wontfix
Status: reopenedclosed

-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.

comment:26 Changed 10 years ago by 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?

comment:27 in reply to:  26 Changed 10 years ago by 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).

comment:28 in reply to:  26 Changed 10 years ago by 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).

comment:29 Changed 10 years ago by vinc17@…

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

comment:30 Changed 10 years ago by 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.

comment:31 in reply to:  30 Changed 9 years ago by 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.

comment:32 Changed 8 years ago by 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...

Note: See TracTickets for help on using tickets.