voc needs update?
leledumbo opened this issue · 14 comments
Taken straight from the 0.1.0.tar.gz archive
cd src
make -f Makefile_linux
...
Making run time library for -O2
../../../src/runtime/Platformunix.Mod Compiling Platform. New symbol file. 14037 chars.
../../../src/runtime/Heap.Mod Compiling Heap. New symbol file. 17463 chars.
-- Couldn't rename temp name as register name: 1f.fd = 4 errcode = 2
Terminated by Halt(99).
make[3]: *** [src/tools/make/oberon.mk:214: runtime] Error 99
make[3]: Leaving directory '/mnt/LinuxShared/MyAUR/freeoberon/src/FreeOberon/data/bin/voc/src'
make[2]: *** [src/tools/make/oberon.mk:389: library] Error 2
make[2]: Leaving directory '/mnt/LinuxShared/MyAUR/freeoberon/src/FreeOberon/data/bin/voc/src'
make[1]: *** [makefile:149: full] Error 2
make[1]: Leaving directory '/mnt/LinuxShared/MyAUR/freeoberon/src/FreeOberon/data/bin/voc/src'
make: *** [Makefile_linux:78: voc] Error 2
voc I built myself compiles and runs just fine.
OK, that's easy. Just use the clone-d git repo. In short: the .tar.gz archive needs update.
Works on my end (Debian, x86_64). What processor are you using?
The error Couldn't rename temp name as register name: 1f.fd = 4 errcode = 2 comes from Files.Mod and just means that during Oberon-to-C translation the compiler couldn't rename the file it just created. Try running with root privileges or make sure that the directory you are working in gives all rights to the user you are logged in as. I.e. execute sudo chown -R youruser:youruser . or sudo chmod -R 777 .. Please try and let me know if it helps. Probably something's wrong with file permissions inside the tar.gz file.
P.S. FreeOberon includes its own (slightly modified) version of voc inside it, however you can easily substitute it with your version or the original voc by editing compile.sh or just moving voc files around. The only change (as far as I remember) is the introduction of the FLOOR(...) built-in function that works exactly like SHORT(ENTIER(...)). This makes it convenient to use REAL type for graphics programming, this also is a built-in function in Oberon-07.
In case it is relevant, I've just updated the link to the English version of the documentation for Free Oberon. It was pointing to the wrong file. Here it is: http://freeoberon.su/files/FreeOberon_v0.1.0_en.pdf
Works on my end (Debian, x86_64). What processor are you using?
Manjaro, x86_64.
Did you just update the archive? I get different error now:
Making run time library for -O2
../../../src/runtime/Platformunix.Mod Compiling Platform. New symbol file. 14037 chars.
../../../src/runtime/Heap.Mod Compiling Heap. New symbol file. 17463 chars.
gcc: error: Heap.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
C compile: gcc -fPIC -g -I "../data/bin/voc/2/include" -c Heap.c
-- failed: status 0, exitcode 1.
Terminated by Halt(1).
And it's repeatable. I already have all the files belong to me and my group (tar does it automatically), still the same. Even chmod 777 -R . gives no change. I already have it working through the git repo, though, but this might be a showstopper for starters.
No, I didn't update the archive. You probably have files left from previous installation. Heap.c is a file that should have been produced by the operation that halted with an error in your previous log:
../../../src/runtime/Heap.Mod Compiling Heap. New symbol file. 17463 chars.
This line means that Heap.sym and Heap.c are being created.
It's a freshly extracted one, I deleted the previous one. I already have standalone voc in /opt/voc, though, if that may conflict (but I don't think so, voc makefile doesn't interfere with installation directory until make install is issued).
I manually invoke the supplied voc in data/bin/voc/src/src/runtime to Heap.Mod, it compiles and produces Heap.c. But if I execute make from data/bin/voc/src, then above error happens. Funny enough, Heap.c is there in build/manjaro.LP64.gcc (it should be there, right?).
Hm... You don't have to execute make from data/bin/voc/src, you need to run make -f Makefile_linux from src. Does it work if you do that or does it do the same thing?
The error happens on this line in data/bin/voc/src/src/tools/make/oberon.mk (this is part of voc make process):
cd $(BUILDDIR)/$(MODEL); $(ROOTDIR)/$(OBECOMP) -Fs -O$(MODEL) ../../../src/runtime/Heap.Mod
On my machine this line evaluates to:
cd build/debian.LP64.gcc/2 ; /home/kekc/tmp/FreeOberon/data/bin/voc/src/voc -Fs -O2 ../../../src/runtime/Heap.Mod
You can see voc executable from data/bin/voc/src is being run. Probably in your case it halts silently with no error (unfortunately, voc does that in case of some errors). The (temporary) voc executable itself is created on the first step of the make process. You can see the line voc created. in the beginning of the output when you run make -f Makefile_linux. Let's compare our outputs. Here is mine:
VERSION: 2.1.0
BRANCH:
Target characteristics:
PLATFORM: unix
OS: debian
BUILDDIR: build/debian.LP64.gcc
INSTALLDIR: /opt/voc
Oberon characteristics:
MODEL: 2
ADRSIZE: 8
ALIGNMENT: 8
C compiler:
COMPILER: gcc
COMPILE: gcc -fPIC -g
DATAMODEL: LP64
voc created.Hm... You don't have to execute make from data/bin/voc/src, you need to run make -f Makefile_linux from src
I know, I'm just testing because the latter is actually causing the error, while the former does not.
Let's compare our outputs. Here is mine:
Here's mine:
VERSION: 2.1.0
BRANCH:
Target characteristics:
PLATFORM: unix
OS: manjaro
BUILDDIR: build/manjaro.LP64.gcc
INSTALLDIR: /opt/voc
Oberon characteristics:
MODEL: 2
ADRSIZE: 8
ALIGNMENT: 8
C compiler:
COMPILER: gcc
COMPILE: gcc -fPIC -g
DATAMODEL: LP64
voc created.
OK, this makes me crazy, now the error is back to:
Making run time library for -O2
../../../src/runtime/Platformunix.Mod Compiling Platform. New symbol file. 14037 chars.
../../../src/runtime/Heap.Mod Compiling Heap. New symbol file. 17463 chars.
-- Couldn't rename temp name as register name: 1f.fd = 4 errcode = 2
Terminated by Halt(99).
Previous error seems to be caused by Heap.c not being flushed to disk fast enough for gcc to find it, which it now does so it returns to previous error. Why it doesn't happen with the one from git repo (both freeoberon and voc itself), I have no idea...
Please run ls -la to see what are the file and directory permissions in the Free Oberon directory. It may have something to do with the file permissions.
When a file is created or renamed by voc, it should be created or renamed instantly, otherwise it doesn't make much sense, otherwise the scripts won't work. But you can try to edit the file data/bin/voc/src/src/tools/make/oberon.mk and add lines to create some delay. I.e. sleep 4 for a 4 second delay.
Did you manage to fix the issue? Is it working now?
Would really appreciate if you could help me replicate the issue and fix it. Also let me know if you find Free Oberon helpful or what could be improved.
I guess it's something with my partition holding the directory. When I move the entire directory to another partition, it works. Can't believe how fast this disk ages...
Probably that has something to do with the file system and not the hard drive. What file systems do you have on those two partitions?
(Seems like the file is not being registered instantly by the file system.)
Both the current and previous partition are btrfs. I might need to fsck the previous one.
I've just updated VOC inside Free Oberon to the latest versions, reimplementing all the changes/edits in FO version of VOC (i.e. Out.WriteFix and the FLOOR procedure), fixed a bug in VOC's Files.WriteSet and module In, fixed all VOC installation warnings.
The editor has also been updated.