Passing --enable-runtime-module-search to configure will cause a segfault in the Perl bindings on shutdown of i.e. git-svn. See http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=138509 for progress reports. Reproducible: Always Steps to Reproduce:
Please write a patch or wait until somebody else writes it. --enable-runtime-module-search has many significant advantages and not using it is unacceptable.
Created attachment 153071 [details, diff] Ebuild patch to disable runtime-module-search and die on configure errors I cannot write a patch, since even the exact cause is not yet know. ;) Currently subversion devs suspect a generic showstopping bug in pool destruction. Since that functionality was already present in 1.4 and was not used by Gentoo, I doubt it is now so extremely necessary to have it in a ~arch masked release candidate. ;)
(In reply to comment #2) > Created an attachment (id=153071) [edit] > Ebuild patch to disable runtime-module-search -1 > and die on configure errors econf always dies on configure errors. This part is totally useless. > Currently subversion devs suspect a generic showstopping bug in pool > destruction. I heard about it. I'm one of them: https://svn.collab.net/viewvc/*checkout*/svn/trunk/COMMITTERS > Since that functionality was already present in 1.4 and was not used by > Gentoo, I doubt it is now so extremely necessary to have it It avoids some problems which happen during incompatible upgrades of some (sometimes indirect) dependencies of Subversion.
How about package.mask-ing the 1.5.0_rc* ebuilds? Why are they in ~arch anyway?
(In reply to comment #4) > How about package.mask-ing the 1.5.0_rc* ebuilds? Wrong idea. > Why are they in ~arch anyway? Because they are needed and useful here. Older versions don't work with libtool-2.*.
The issue is *still* present in rc9. Can you please either fix the segfaults immediately, or disable runtime module search? This is getting annoying...
Created attachment 156927 [details, diff] Workaround
(In reply to comment #7) dev-util/git[subversion] should depend on dev-util/subversion[-dso].
For that matter it should be "anything-that-uses-subversion-bindings" should depend on "subversion -dso"... But the general idea seems like an acceptable compromise.
fixed in 1.5.0_rc9-r1
(In reply to comment #9) > For that matter it should be "anything-that-uses-subversion-bindings" should > depend on "subversion -dso"... Maybe only Subversion Perl bindings. We didn't hear about problems with Python or Ruby bindings.
I still see this issue in 1.5.1. (With USE=dso.) Is there anything known about a real fix (besides disabling runtime-module-search)?
(In reply to comment #10) > fixed in 1.5.0_rc9-r1 > Where is the fix? If you meant the introduction of the dso useflag, that seems like a step in the right direction, but could you at least echo a big warning if this is enabled? Git svn failed on me and I had now idea where this came from...
Duplicated in bug #223747 ?
According to http://subversion.tigris.org/issues/show_bug.cgi?id=3289 the configure flag in question is "unsupported, experimental and known to break things"; this seems like a very bad idea to have as a default...
