I have been trying to write a kernel call in Minix 3. I looked at the developer's guide and tried doing it, but came across an error in step 9.
# make /usr/src/${MACHINE_ARCH}
install ===> tools
install ===> lib
install ===> lib/csu
install /usr/lib/crt0.o
*** Error code 1
Stop.
make: stopped in /usr/src/lib/csu
*** Error code 1
Stop.
...
...
The error has been shown above. The link I followed is:
http://wiki.minix3.org/Releases/3.2.1/DevelopersGuide/NewKernelCall
Any idea why this error has come up? Or are there any other guides available in the internet? I haven't found any unfortunately.
Have you checked if the environment variable $MACHINE_ARCH is set?
Try this on your prompt:
echo $MACHINE_ARCH
Related
Just received a new GTX laptop, and for whatever reason, I am simply not able to install rJava. No matter what I do with the Java and JDK installs, I get the following message. I have been uninstalling, rebooting, re-installing, Java (latest versions) and RTools, and yet, I still cannot get rJava to install.
I am using Rstudio as my gui, and I have been able to successfully install rJava on an Ubuntu machine, but for whatever reason, I cannot get this to work on my windows GPU laptop.
I realize this is a question that appears to have been answered in other threads, but I am not seeing the same situation as mine. Something is different, and I can't figure it out.
What else can I provide to help someone help me?
* installing *source* package 'rJava' ...
** package 'rJava' successfully unpacked and MD5 sums checked
** using staged installation
Generate Windows-specific files (src/jvm-w32) ...
make: Entering directory '/Users/bfcgl/AppData/Local/Temp/RtmpOcP1l8/R.INSTALLa750514e17ed/rJava/src/jvm-w32'
C:/Rtools/mingw_64/bin/dlltool --as C:/Rtools/mingw_64/bin/as --input-def jvm64.def --kill-at --dllname jvm.dll --output-lib libjvm.dll.a
C:/Rtools/mingw_64/bin/gcc -O2 -c -o findjava.o findjava.c
C:/Rtools/mingw_64/bin/gcc -s -o findjava.exe findjava.o
make: Leaving directory '/Users/bfcgl/AppData/Local/Temp/RtmpOcP1l8/R.INSTALLa750514e17ed/rJava/src/jvm-w32'
Find Java...
JAVA_HOME=C:/PROGRA~1/Java/jdk-14
=== Building JRI ===
JAVA_HOME=C:/PROGRA~1/Java/jdk-14
R_HOME=C:/PROGRA~1/R/R-36~1.3
JDK has no javah.exe - using javac -h . instead
Creating Makefiles ...
Configuration done.
make -C src JRI.jar
make[1]: Entering directory '/Users/bfcgl/AppData/Local/Temp/RtmpOcP1l8/R.INSTALLa750514e17ed/rJava/jri/src'
C:/PROGRA~1/Java/jdk-14/bin/javac -h . -d . ../RList.java ../RBool.java ../RVector.java ../RMainLoopCallbacks.java ../RConsoleOutputStream.java ../Mutex.java ../Rengine.java ../REXP.java ../RFactor.java ../package-info.java
..\Rengine.java:120: error: invalid use of a restricted identifier 'yield'
while (!alive && !died) yield();
^
(to invoke a method called yield, qualify the yield with a receiver or type name)
1 error
make[1]: *** [Makefile.all:41: org/rosuda/JRI/Rengine.class] Error 1
make[1]: Leaving directory '/Users/bfcgl/AppData/Local/Temp/RtmpOcP1l8/R.INSTALLa750514e17ed/rJava/jri/src'
make: *** [Makefile.all:19: src/JRI.jar] Error 2
**** WARNING: JRI could NOT be built
Set IGNORE=1 if you want to build rJava anyway.
ERROR: configuration failed for package 'rJava'
* removing 'C:/Users/bfcgl/OneDrive/Documents/R/win-library/3.6/rJava'
Warning in install.packages :
installation of package ‘rJava’ had non-zero exit status
I had the same problem (although installing for the first time on an old laptop) and can confirm that JDK 11 solved the problem
I still looking for the same problem resolution, meanwhile, I tried with Java JDK 11 and I succeed in RStudio. If this helps, try it. I will keep searching for the answer why the new version is not working.
Regards,
I had installed Julia 0.4.5 with sudo apt install julia. Now I want to install the latest version of Julia v0.6.0. First I git clone the source code from the Github, then I install lots of the dependencies following the installing instruction. And all is fine.
When I start to make, waiting a long time, and it show:
Making install in TESTS
Making install in EXAMPLES
Making install in BAND
Making install in COMPLEX
Making install in NONSYM
Making install in SIMPLE
Making install in SVD
Making install in SYM
make[2]: *** No rule to make target '/home/yaoyu/julia/src/support/hashing.o', needed by '/home/yaoyu/julia/src/support/libsupport.a'. Stop.
Makefile:208: recipe for target 'support/libsupport.a' failed
make[1]: *** [support/libsupport.a] Error 2
Makefile:55: recipe for target 'julia_flisp.boot.inc.phony' failed
make: *** [julia_flisp.boot.inc.phony] Error 2
I have searched for answers in this web, while cann't find the way to fix it, I don't know what causes that ? Anyone konws how to correct it? Thanks a lot.
I'm following the instruction here http://www.teratotech.com/blog/xcode-7-steps-to-easily-switch-between-multiple-environments/ to generate different schemes for different environments..
I created a testing configuration and created a new scheme to use that configuration. However, when I build and run, I'm getting this error:
<unknown>:0: error: generate-pch command failed with exit code 1 (use -v to see invocation)
error: 'AFNetworking/AFNetworking.h' file not found
#import <AFNetworking/AFNetworking.h>
1 error generated.
<unknown>:0: error: failed to emit precompiled header '/var/folders/f2/6j4b4kz54xy1vf_2gdlnrllc0000gn/T/My-Project-Header-47bffb.pch' for bridging header '/Users/me/Dev/my-project/My-Project-Header.h'
When I build with my original scheme, everything's fine... I only have 1 target. Am I missing anything?
EDIT: I'm using Cocoapods to manage my dependencies, if that makes any difference.
i solved this issue by running below commands
$ pod repo update
$ pod install
Usually such issue happens when project directory is changed or copied form some other machine.
I'm having trouble reinstalling ProFTPD on a FreeBSD 10.1 setup. The server is newly upgraded from 10.0 to 10.1. When I start the make install clean process, these warnings first shows on screen.
===> proftpd-1.3.5_4 depends on shared library: libpcre.so
/usr/share/misc/magic, 93: Warning: Printf format `l' is not valid for type `lelong' in description `, %ld pages'
...
/usr/share/misc/magic, 15118: Warning: Printf format `l' is not valid for type `belong' in description `Volume %ld,'
/usr/share/misc/magic, 15609: Warning: Current entry does not yet have a description for adding a MIME type
file: File 5.19 supports only version 12 magic files. `/usr/share/misc/magic.mgc' is version 8
[: =: unexpected operator
- not found
And after i while, the make process stops with this error:
/bin/ln -s libpcre.so.1 /usr/ports/devel/pcre/work/stage/usr/local/lib/libpcre.so.3
====> Compressing man pages (compress-man)
===> Installing for pcre-8.35_2
===> Checking if pcre already installed
===> pcre-8.35_2 is already installed
You may wish to ``make deinstall'' and install this port again
by ``make reinstall'' to upgrade it properly.
If you really wish to overwrite the old port of pcre
without deleting it first, set the variable "FORCE_PKG_REGISTER"
in your environment or the "make install" command line.
*** Error code 1
Stop.
make[3]: stopped in /usr/ports/devel/pcre
*** Error code 1
Stop.
make[2]: stopped in /usr/ports/devel/pcre
*** Error code 1
Stop.
make[1]: stopped in /usr/ports/ftp/proftpd
*** Error code 1
Stop.
make: stopped in /usr/ports/ftp/proftpd
Seems that the file /usr/share/misc/magic.mgc is of a wrong version?
This might happens when I was upgrading from 10.0-RELEASE-p12 to 10.1-RELESE-p1?
If i run make install clean of the ProFTP port, and disable support for pcre, the process and install is successful.
But I believe that something is still broken?
My programming skills are limited, and also this level of error.
Please let me know if you have any ideas,
Thanks,
First of all, proftpd 1.3.5 is available as a binary package, it's much simpler to install it that way (pkg install proftpd).
Second - at first it looked like a port bug; as Etan said, there is a shell syntax error (something like '[ x == y ]' instead of '[ x = y ]'); those are common, and ports contain patches to fix those. However, there is a binary package, and packages are built from ports ("make package"), so port obviously does work on package build machines. So it's probably something specific to your environment.
If you really want to build from ports, try this: first, reinstall pcre. For some reason it had to be rebuilt, but failed to install, because it's already installed. So, "cd /usr/ports/*/pcre && make clean all deinstall reinstall". That should get rid of the second error. Then go back to "../*/proftpd" and see how far it goes.
But really, I'd try packages first. They have nothing in common with old pkg_add system, and are really nice.
freebsd-update diff for FreeBSD-SA-14:28.file seems wrong, and it breaks file(1).
Therefore simply pkg install file will be a workaround.
I'm running Fedora 9 x86_64 and am more or less a Linux newbie (not using it, but installing and such). The error occurs in the second stage of the bootstrap (i.e. "./bootstrap_stage2").
It does a whole lot fo stuff and then these errors start happening:
Fatal error: exception Out_of_memory
make[8]: *** [odoc_html.cmo] Error 2
make[8]: Leaving directory `/home/matthew/godi/build/godi/godi-ocaml/work/ocaml/ocamldoc'
make[7]: *** [ocamldoc] Error 2
make[7]: Leaving directory `/home/matthew/godi/build/godi/godi-ocaml/work/ocaml'
Error: Exec error: File /home/matthew/godi/build/godi/godi-ocaml/./../../mk/bsd.pkg.mk, line 1039: Command returned with non-zero exit code
Error: Exec error: File /home/matthew/godi/build/godi/godi-ocaml/./../../mk/bsd.pkg.mk, line 1378: Command returned with non-zero exit code
Error: Command fails with code 1: godi_console
Failure!
I've run it monitoring my memory and can say that I definately have not run out (using about 500 and I've got 3).
So anyone know what the issue is? I've searched the net, but the only other similar thing I found was the other thread on here (but it had a different error)
Any help would be much appreciated, because last time I installed it, it worked flawlessly.
This looks like a known problem with old OCaml (<3.11) on 64-bit platforms likely triggered by heap randomization, which is enabled on Fedora. It's been fixed so far as I know in recent releases (3.11 at least, possibly 3.10.2). Up-to-date GODI running out of section 3.11 should work if this is the case.