| Summary: | dev-util/subversion-1.3 ebuild fails on bad --with-apr | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David Ripton <dripton> |
| Component: | New packages | Assignee: | Paul de Vrieze (RETIRED) <pauldv> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | rich0, znmeb |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge info from failed subversion install | ||
|
Description
David Ripton
2005-01-19 04:52:13 UTC
When you just unmerged apr, you removed all apr implementations your system has. The problem is that the 1.1.3 version is NOT compatible with 1.1.2-r1 (which I didn't make). While I support going to an external apr/apu I did not make the -r1 ebuild, which can not work without apr. To support a new subversion version I can't use the apr-utils using ebuild. What you should do in your situation is to remerge apr/apr-utils and then merge with --nodeps. Paul, your --nodeps workaround worked fine for me. Thanks. Could this be documented somewhere, like in a subversion "ewarn" or something? I ran into this and I had to truck through **262** subversion bugs to find the relevant one, only to find out that there was a workaround and not a fix. Apparently "emerge kde-meta" to pull in KDE 3.4 requires subversion, so this is likely to hit a bunch of bleeding edgers like me who want KDE 3.4. Edward. I don't know what bug you have hit, but this particular bug was caused by a masked version of subversion that was never valid. If you want to use apr, you must use the 1.1.3-r1 ebuild that does use the external apr library. Created attachment 54127 [details]
emerge info from failed subversion install
Well ... here goes ... emerge -v --nodeps subversion (1.1.3-r1) yields cd subversion/clients/cmdline && /bin/sh /var/tmp/portage/subversion-1.1.3-r1/work/subversion-1.1.3/libtool --silent --mode=link i686-pc-linux-gnu-gcc -L/var/tmp/portage/subversion-1.1.3-r1/image//usr/lib -O2 -march=i686 -pipe -fomit-frame-pointer -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -pthread -DNEON_ZLIB -DNEON_SSL -L/usr/lib -rpath /usr/lib -o svn add-cmd.o blame-cmd.o cat-cmd.o checkout-cmd.o cleanup-cmd.o commit-cmd.o copy-cmd.o delete-cmd.o diff-cmd.o export-cmd.o help-cmd.o import-cmd.o info-cmd.o log-cmd.o ls-cmd.o main.o merge-cmd.o mkdir-cmd.o move-cmd.o notify.o prompt.o propdel-cmd.o propedit-cmd.o propget-cmd.o proplist-cmd.o props.o propset-cmd.o resolved-cmd.o revert-cmd.o status-cmd.o status.o switch-cmd.o update-cmd.o util.o ../../../subversion/libsvn_client/libsvn_client-1.la ../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../subversion/libsvn_ra/libsvn_ra-1.la ../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/lib/libaprutil-0.la -lgdbm -ldb -lexpat /usr/lib/libapr-0.la -lrt -lm -lcrypt -lnsl -lpthread -ldl -lneon -lz -lssl -lcrypto -ldl -lxml2 -lz -lpthread -lm /usr/lib/libaprutil-0.so: undefined reference to `db_create_4001' /usr/lib/libaprutil-0.so: undefined reference to `db_strerror_4001' collect2: ld returned 1 exit status distcc[15715] ERROR: compile (null) on localhost failed make: *** [subversion/clients/cmdline/svn] Error 1 !!! ERROR: dev-util/subversion-1.1.3-r1 failed. !!! Function src_compile, Line 103, Exitcode 2 !!! make of subversion failed !!! If you need support, post the topmost build error, NOT this status message. I've attached the output of "emerge info"; it's huge. In any event, I ran into essentially the same situation reported by the original poster -- a block, which I attempted to resolve by unmerging apr, and following the advice here, I attempted to fix by reinstalling apr and then doing the emerge of subversion with --nodeps. Yeah, known bug. I'll try to create a fix for it. It's the problem of apr not specifying completely which berkeley db it should link with. Should this bug be closed - or should a new one be opened? The comments lead into another bug, which you suggest that you're going to fix. However, I couldn't find any other reference to that bug - should one be created? I'll gladly file it, but I don't want to dupe something else if it is just hiding. Any workarounds for this - I'm trying to emerge kde 3.4. My fix would in the first place just suggest the workaround. The "fix"/workaround is to remerge apache-2 (stable) or apr and apr-util (unstable). After that subversion should build correctly. Alternatively you could edit apu-config to have it specify the correct include dir for the used db version. |
