"emerge nmh" fails with the following message: --------------------------- ACCESS VIOLATION SUMMARY--------------------------- LOG FILE = "/tmp/sandbox-nmh-1.0.4-7475.log" open_wr: /.nonexist-file.swp open_wr: /.nonexist-file.swp open_wr: /root/tmp/nonexist-file.swp open_wr: /root/tmp/nonexist-file.swp -------------------------------------------------------------------------------- The machine details are: Linux ivpcl04 2.4.19-r1 #2 Thu May 2 10:05:56 BST 2002 i686 GenuineIntel from /etc/make.conf: CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe" CXXFLAGS="-march=i686 -O3 -pipe"
I can't replicate this. What portage version are you using?
I used portage-1.9.5. When 1.9.6 becomes available from http://www.ibiblio.org/gentoo/snapshots/ I'll try that too. I can't use "emerge rsync" at present: >>> starting rsync with rsync://cvs.gentoo.org/gentoo-x86-portage... rsync: failed to connect to cvs.gentoo.org: Connection refused rsync error: error in socket IO (code 10) at clientserver.c(89)
Portage 1.9.6 gives the same result.
I can't reproduce this either with 1.9.6-r1. The depends for this ebuild are slightly wrong though and i'll correct that. In the meantime, please post your USE flags.
cleaned up ebuild for recent portages in -r1
I used the default USE flags for 1.1a. I succeeded in getting nmh to work by downloading the source from http://www.mhost.com/nmh/ and compiling it.
I still can't reproduce this even by matching your USE set. I'll reopen this bug and assign it to seeman@gentoo.org so that he can delegate it to other developers who may be able to reproduce it.
seemant, i can't reproduce this one to fix it.
I've now tried this on an Athlon in addition to the P4 on which I first reported the problem, with exactly the same results. Both machines were built with the stage 3 tar file (rsync is blocked).
Az, help!
Dont know .. tried it in a xterm .. console ... "su" to root and not "su -", but it works every time. Do understand, Im not saying that you do not have this problem .. its rather some ENV variable set, or not set, or some or other package that is installed, or not, or not a certain version ... Maybe do: # cd /var/db/pkg # find . > /tmp/foo and mail foo also attatch the output of "set" (all the env variables). What might be interesting, is if you could try to use the 16mb image and do a build from there and then try merging nmh, rather than stage 3.
I also have exactly the same problem... What I do is cross-compile in a chrooted environment, from stage 1 only. All other packages I've emerged up to now worked. I also use 1.1.a; USE="-mmx -3dnow -sse", CFLAGS="-mcpu=i486 -march=i486 -fomit-frame-pointer -O3 -fno-exceptions -funroll-loops" (That's why I cross-compile :-). Apart from that, nothing special at all. Hope this helps...
Just a "Me Too". nmh-1.0.4-r1 with portage version 1.9.13. With the following: USE="-kde -gnome alsa -arts tcltk ncurses readline gif png tiff jpeg -esd imap spell tetex gpm -3dnow qt python perl oogvorbis opengl sdl -postgres truetype empeg encode mmx xml -cups" CHOST="i686-pc-linux-gnu" CFLAGS="-march=i686 -O3 -pipe" CXXFLAGS="-march=i686 -O3 -pipe" I've tried it from the console and from a rxvt term in WindowMaker. Here's the result of set on my machine. This is a pretty new install from earlier in the week. BASH=/bin/bash BASH_VERSINFO=([0]="2" [1]="05a" [2]="0" [3]="1" [4]="release" [5]="i686-pc-linux-gnu") BASH_VERSION='2.05a.0(1)-release' CLASSPATH=/opt/blackdown-jdk-1.3.1/jre/lib/rt.jar COLORFGBG='default;default;0' COLORTERM=rxvt-xpm COLUMNS=80 CVS_RSH=ssh DIRSTACK=() DISPLAY=:0.0 EDITOR=/usr/bin/nano EUID=1000 GNUSTEP_LOCAL_ROOT=/usr/lib/GNUstep GROUPS=() HISTFILE=/home/destefan/.bash_history HISTFILESIZE=500 HISTSIZE=500 HOME=/home/destefan HOSTNAME=adx.destefan.homeip.net HOSTTYPE=i686 IFS=$' \t\n' INFODIR=/usr/share/info:/usr/X11R6/info INPUTRC=/etc/inputrc JAVAC=/opt/blackdown-jdk-1.3.1/bin/javac JAVA_HOME=/opt/blackdown-jdk-1.3.1 JDK_HOME=/opt/blackdown-jdk-1.3.1 LESSOPEN='|lesspipe.sh %s' LINES=24 LOGNAME=destefan LS_COLORS='no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.png=01;35:*.mpg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:' MACHTYPE=i686-pc-linux-gnu MAILCHECK=60 MANPATH=/usr/share/man:/usr/X11R6/man MOZILLA_FIVE_HOME=/usr/lib/mozilla OLDPWD=/home/destefan OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PAGER=/usr/bin/less PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/opt/blackdown-jdk-1.3.1/bin:/o pt/blackdown-jdk-1.3.1/jre/bin:/usr/qt/3/bin PIPESTATUS=([0]="0") PPID=5359 PS1='\[\033[01;32m\]\u@\h \[\033[01;34m\]\W \$ \[\033[00m\]' PS2='> ' PS4='+ ' PWD=/tmp QMAKESPEC=linux-g++ QTDIR=/usr/qt/3 SHELL=/bin/bash SHELLOPTS=braceexpand:hashall:histexpand:monitor:history:interactive-comments:emacs SHLVL=1 TERM=xterm UID=1000 USER=destefan VIMRUNTIME=/usr/share/vim/vim61 WINDOWID=8388610 WMAKER_BIN_NAME=wmaker WRASTER_COLOR_RESOLUTION0=4 XINITRC=/etc/X11/xinit/xinitrc _=/etc/make.conf
Finally got it to work by re-installing the machine from stage 1.
This occurs when there is no valid /usr/bin/vi. Even just a symlink to /usr/bin/vim fixes this problem (I had this). So for now added app-editors/vi as DEPEND until somebody with more time can resolve this in a more fasionable way.
Sorry but I do have a link from vim to /usr/bin/vi, and I'm still unable to emerge, with the same error...
OK, scrap the symlink from /usr/bin/vim to /usr/bin/vi as a fix then. You need vi installed, AFAIK.
Ok, for some weird reason I cannot reproduce it anymore. Can somebody with this problem try the following: Edit /usr/lib/portage/bin/ebuild.sh and search for the line: export S D then add just below it: export TMPDIR="${T}" Giving you: ------------------------snip------------------------------------ #our custom version of libtool uses $S and $D to fix #invalid paths in .la files export S D export TMPDIR="${T}" src_compile cd ${BUILDDIR} touch .compiled if [ ! -e "build-info" ] then mkdir build-info fi cd build-info ------------------------snip------------------------------------ And try to remerge nmh.
No luck with the fix, but emerging vi did solve the problem. Seems like there's some weird kind of dependency with vi indeed...
Ok, so stock should work now.
The solution in comment #18 did not fix the problem. Using /home/cvsroot/gentoo-src/portage/bin/ebuild.sh,v 1.125 2003/05/12 09: 10:27, which has the changes mentioned: #some users have $TMP/$TMPDIR to a custom dir in their home ... #this will cause sandbox errors with some ./configure #scripts, so set it to $T. export TMP="${T}" export TMPDIR="${T}" I still get the access violation. For nmh-1.0.4-r2.ebuild, app-editors/vi is still listed as a dependency. The above problem occurs only when that dependency is removed. However, who wants to merge app-editors/vi? It sucks (IMHO). I think a better solution may be to make all the VIs provide virtual/vi and make nmh depend on virtual/vi. Since nmh seems to be used by myself and a few other people, a sufficient hack may be to simply change nmh-1.0.4-r2.ebuild to have [ -f /usr/bin/vi ] || die in src_compile().
