subversion links to previous install

[michaelld (Michael Dickens)]

Make sure subversion is installed without +universal, and that there is no +universal to activate. Then, do

sudo port -d install subversion +universal > svn_out.txt 2>&1

Review the file "svn_out.txt" you'll find a bunch of references to ${prefix}/lib/libsvn_FOO not being having the correct arch. The attached patch, obtained from

cd `port dir subversion`
svn diff > ~/Desktop/subversion_svn.diff

work for me to correct this issue.

[michaelld (Michael Dickens)]

"svn diff" in 'subversion' dports directory; patches to keep subversion from including and linking to install in ${prefix}

[danielluke (Daniel J. Luke)]

Warnings when linking:

ld: warning: in /opt/local/lib/libsvn_delta-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_diff-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_subr-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_ra_local-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_repos-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_fs-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_fs_fs-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_fs_base-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_fs_util-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_ra_svn-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_ra_neon-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libsvn_ra_serf-1.dylib, file was built for unsupported file format which is not the architecture being linked (i386)

although the resulting binary looks fine. Have you attempted to report this upstream?

[michaelld (Michael Dickens)]

I have not reported it upstream yet; just found it last night :) I agree that that the resulting binaries look fine, so it's not a critical problem. I'm also not 100% convinced that my patches works, but it's the best I could come up with in short order. Ideally, upstream would fix the issue on their side and the Portfile here would not put ${prefix}/include or ${prefix}/lib into any configure environment flags or arguments.

[danielluke (Daniel J. Luke)]

I don't think that that's useful as a general rule, though (sometimes you need a port to look in ${prefix}/include or ${prefix}/lib to pick up a MacPorts library). There's probably some magic one can do to make sure the source directory is picked up first when searching for linking, though.

[michaelld (Michael Dickens)]

I didn't quite get that correct either. What I've been doing in my ports is to remove ${prefix}/include and ${prefix}/lib from *FLAGS (e.g., CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc.) and adding them to *PATH instead (CPATH and LIBRARY_PATH). That way, when all else fails the compiler will still look to those paths for headers & libraries -- but only when all else fails. Doing this helps keep the path ordering correct internal to the build; should be: internal_paths followed by external_paths and system_paths (generally in whatever order for these last 2). When using Autotools, CMake, or QMake (which represent most of the ports), having "-L${prefix}/lib" at the start of LDFLAGS almost always results in that directory being searched before any others -- which isn't the correct ordering though it does work most of the time since most ports do not require internal linking.

[danielluke (Daniel J. Luke)]

If you do report it upstream, can you note the upstream bug report here too? Thanks.

[michaelld (Michael Dickens)]

Will do, if I do. I'm pretty sure the changes would be simple in the Autotools scripts used by subversion -- but I'd rather it be an SEP; got enough on my plate already.

[ryandesign (Ryan Carsten Schmidt)]

Replying to michaelld@…:

adding them to *PATH instead (CPATH and LIBRARY_PATH).

MacPorts already sets CPATH and LIBRARY_PATH for you.

[vinc17@…]

Looks like a dup of bug #18937 (the context is a bit different, but the cause is the same, IMHO: when Subversion is built, it sometimes try to link with the currently installed version instead of the library that has just been built). The problem here is due to "-rpath /opt/local/lib" used in the build. In the case of bug #18937, the consequence is worse since the interface has changed between 1.5.x and 1.6.x, so that this gives a build error.

Note that it has been reported that Leopard does not have this problem.

[michaelld (Michael Dickens)]

Replying to ryandesign@…:

MacPorts already sets CPATH and LIBRARY_PATH for you.

Yes, that's true, and by default too. Which continues to make me wonder why -L${prefix}/lib is in LDFLAGS and -I${prefix}/include is in CPPFLAGS by default. By now, I'd assume those would be set only when necessary because the port's build system doesn't honor CPATH or LIBRARY_PATH somehow. In my upgrading from non-universal to universal, almost every port I've upgraded requires me to remove those flags so-as to not reference the already-installed headers and libraries.

[michaelld (Michael Dickens)]

Replying to vinc17@…:

Looks like a dup of bug #18937

Yup; that's the issue. I did play around with my patch & it almost fixes the issue; I can get subversion's build system to not use the already-installed headers and libraries (and build and install itself correctly), but it only builds static libraries for now -- no idea why not shared ones.

[vinc17@…]

This is in fact 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