Looks like it is sandbox related =/ /public/tmp/linux-64/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6628: /home/jolexa/portage/linux-64/bin/sed: Cannot allocate memory libtool: install: warning: `/public/tmp/linux-64/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/subversion/libsvn_subr/libsvn_subr-1.la' has not been installed in `/home/jolexa/portage/linux-64/usr/lib' libsandbox: max_envp_len too big! /public/tmp/linux-64/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6628: /home/jolexa/portage/linux-64/bin/sed: Cannot allocate memory libtool: install: warning: `../../subversion/libsvn_subr/libsvn_subr-1.la' has not been installed in `/home/jolexa/portage/linux-64/usr/lib' libsandbox: max_envp_len too big! /public/tmp/linux-64/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6669: /home/jolexa/portage/linux-64/bin/sed: Cannot allocate memory /home/jolexa/portage/linux-64/usr/bin/install -c /public/tmp/linux-64/portage/dev-util/subversion-1.6.2/image//home/jolexa/portage/linux-64/usr/bin/svnadmin libsandbox: max_envp_len too big! /public/tmp/linux-64/portage/dev-util/subversion-1.6.2/work/subversion-1.6.2/libtool: line 6691: /home/jolexa/portage/linux-64/usr/bin/install: Cannot allocate memory make: *** [install-bin] Error 126 * ERROR: dev-util/subversion-1.6.2 failed: * Installation of core of Subversion failed * * Call stack: * ebuild.sh: 49: <call src_install> * environment:6080: emake -j1 DESTDIR="${D}" local-install || die "Installation of core of Subversion failed"; * * If you need support, post the topmost build error, and the call stack if relevant.
Created attachment 192609 [details] build.log
under interix i had the to mask subversion 1.6.2 for now, since the loader refused to start some of the coreutils during install. (the loader said things like: ls: error in loading shared objects: unresolved symbol: __argv - oops :)). seems something in the environment is wrong, or maybe some loop thats growing something out of it's limits?
I have the same problem. 1.6.1 builds just fine, but 1.6.2 fails.
# Jeremy Olexa <darkside@gentoo.org> (05 Jun 2009) # Fails to build on multiple system types. bug 271424 =dev-util/subversion-1.6.2
Had the same problem. I guess the reason was sandbox didn't receive an update: * sys-apps/sandbox Latest version available: 1.6-r2 Latest version installed: 1.2.18.1-r2 Size of files: 299 kB Homepage: http://www.gentoo.org/ Description: sandbox'd LD_PRELOAD hack License: GPL-2 So after "emerge --update sandbox", I was able to upgrade subversion too: 1244900609: === Unmerging... (dev-util/subversion-1.5.6) 1244900610: >>> unmerge success: dev-util/subversion-1.5.6 1244900618: === (1 of 1) Post-Build Cleaning (dev-util/subversion-1.6.2::/usr/portage/dev-util/subversion/subversion-1.6.2.ebuild) 1244900618: ::: completed emerge (1 of 1) dev-util/subversion-1.6.2 to / 1244900618: *** Finished. Cleaning up... 1244900618: *** exiting successfully. 1244900618: *** terminating.
I also had the unupdated sandbox as previous comment. "emerge --update sandbox subversion" worked for me.
The masked versions of sandbox have issues. You shouldn't even be able to update sandbox with a freshly synced tree. =/
Same problem for me. "emerge --update sandbox subversion" worked for me too.
You don't need a masked version of sandbox. Tha latest stable sandbox (1.6-r2) works fine. Now subversion-1.6.2 just needs to depend on >=sys-apps/sandbox-1.6* and all's well...
arfrever: Originally a Gentoo Prefix issue but based on user comments it is a global issue. This is also the problem in Gentoo Prefix, but we don't have a working sandbox version that satisfies this condition.
I can't reproduce any problems described in this bug. Maybe it's a bug in libtool or sandbox...
it's likely prefix specific, but I can't reproduce with sandbox-2.0 here on Fedora.
(In reply to comment #12) > it's likely prefix specific, but I can't reproduce with sandbox-2.0 here on > Fedora. > i don't even have sandbox on interix, and am experiencing problems - although they sound a little different, it seems that the dynamic loader is out of memory in my case. maybe something with the environment?
subversion-1.6.2 (client) seems to work on AIX.
sandbox maintainers: Do you have an idea what can cause this bug?
you're using sandbox-1.2.x. that error is coming from code in sandbox that doesnt even exist anymore. i dont really plan on trying to look into let alone fix that on the sandbox side. all i can say is run `emerge --verbose` and make sure you dont have any excessively large environment settings in there, or large number of environment variables in the first place.
sandbox-1.2.18.1-r2 is still in the tree and marked stable. Without an "emerge -uD world" or an explicit "emerge sandbox" users will stay on this sandbox version and fail to compile subversion-1.6.2. As sandbox-1.6-r2 is stable on all archs, what prevents us from forcing all users to upgrade to the latest stable?
that's a prefix issue. seeing as there doesnt appear to be any problems with sandbox-1.6+, nothing for sandbox to do here.
we gave up on sandbox for now, so nothing to do for prefix either.
I can update dependency on sys-apps/sandbox...
*** Bug 276806 has been marked as a duplicate of this bug. ***
Fixed.
Actually, for the record. If you don't have FEATURES=sandbox enabled, then there isn't a dep on sandbox at all. So, this will be an improper dep for subversion.
(In reply to comment #23) > Actually, for the record. If you don't have FEATURES=sandbox enabled, then > there isn't a dep on sandbox at all. So, this will be an improper dep for > subversion. > Can we access $FEATURES in ebuild to check if sandbox is enabled?
(In reply to comment #24) > Can we access $FEATURES in ebuild to check if sandbox is enabled? No.
(In reply to comment #25) > No. So maybe a patch to portage to allow that is the proper way to resolve this bug?
hi Arfrever, It appears this failure with sandbox-1.2.18.1 is caused by the addition of subversion-1.6.2-local_library_preloading.patch in conjunction with --enable-local-library-preloading. If I back out the patch or change enable to disable for that config option the build finishes ok. For my own knowledge, could you shed some light on this patch and what it does? Is it safe to drop this patch and build subversion-1.6.x without it if I must stick with sandbox-1.2.18.1 for the moment? Is the patch being pushed upstream and if so, is there a URL to an upstream tracker for it? btw, I suspect this is the sandbox patch that is interfering: http://bugs.gentoo.org/attachment.cgi?id=26533
(In reply to comment #27) > It appears this failure with sandbox-1.2.18.1 is caused by the addition of > subversion-1.6.2-local_library_preloading.patch in conjunction with > --enable-local-library-preloading. If I back out the patch or change enable > to disable for that config option the build finishes ok. > > For my own knowledge, could you shed some light on this patch and what it > does? This patch causes using locally built libraries instead of libraries from /usr/$(get_libdir) during running of tests. > Is it safe to drop this patch and build subversion-1.6.x without it if I must > stick with sandbox-1.2.18.1 for the moment? If you don't plan to run tests, then yes. > Is the patch being pushed upstream I had committed this patch to upstream repository and next I backported it to Gentoo. The changes from this patch will be included in Subversion 1.7.0. http://svn.collab.net/viewvc/svn/trunk/build/transform_libtool_scripts.sh?view=log > and if so, is there a URL to an upstream tracker for it? No.
