I was a react native project but it throws error everytime. I tried to add pakages to my node project earlier it throws the same error always. I've tried to update it. but It's hopeless.
PS C:\Users\sarth\Desktop\app> npm i -g react-app
C:\Users\sarth\AppData\Roaming\npm\node_modules\npm\lib\utils\replace-info.js:13
result += cleanUrl(str.slice(index, match.index)) + match[0]
^
TypeError: cleanUrl is not a function
at splitAndReplace (C:\Users\sarth\AppData\Roaming\npm\node_modules\npm\lib\utils\replace-info.js:13:15)
at replaceInfo (C:\Users\sarth\AppData\Roaming\npm\node_modules\npm\lib\utils\replace-info.js:23:12)
at process.exitHandler (C:\Users\sarth\AppData\Roaming\npm\node_modules\npm\lib\utils\exit-handler.js:168:26)
at process.emit (node:events:520:28)
at process._fatalException (node:internal/process/execution:164:25)
This error always persist when I'm using terminal like powershell and command prompt. But it work fine on a downloaded terminal called Hyper which is truly doesn't make any sense.
Any help will be appreciated. Thanks in advance
Try delete folder npm in path "C:\Users****\AppData\Roaming\npm"
I had the same problem after updating npm version
I am trying to get a basic cross compiler for the BeagleBone Black setup.
I tried to follow this tutorial but ran into some snags...
When dowloading the toolchain for the arm platform the tutorial showed the "gcc-arm-linux-gnueabi" as a package for Ubunto so I figutred there would be one for Debian... No dice, the closest I could find is the "arm-none-eabi" package. Being new to this I gave it a shot.
I made a simpe "Hello World" application as the tutorial suggested and it compiles under the standard tools. Under the cross tools however, I add the prefix amr-none-eabi- and the path /usr/bin/ the following is the result of the build.
make all
Building file: ../src/test.cpp
Invoking: Cross G++ Compiler
arm-none-eabi-g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP MF"src/test.d" -MT"src/test.d" -o "src/test.o" "../src/test.cpp"
Finished building: ../src/test.cpp
Building target: test
Invoking: Cross G++ Linker
arm-none-eabi-g++ -o "test" ./src/test.o
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-exit.o): In function `exit':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/exit.c:70: undefined reference to `_exit'
makefile:45: recipe for target 'test' failed
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-abort.o): In function `abort':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/stdlib/../../../../../newlib/libc/stdlib/abort.c:63: undefined reference to `_exit'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-fstatr.o): In function `_fstat_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/fstatr.c:62: undefined reference to `_fstat'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-openr.o): In function `_open_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/openr.c:59: undefined reference to `_open'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/sbrkr.c:58: undefined reference to `_sbrk'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-signalr.o): In function `_kill_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/signalr.c:61: undefined reference to `_kill'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-signalr.o): In function `_getpid_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/signalr.c:96: undefined reference to `_getpid'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-writer.o): In function `_write_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/writer.c:58: undefined reference to `_write'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-closer.o): In function `_close_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/closer.c:53: undefined reference to `_close'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-isattyr.o): In function `_isatty_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/isattyr.c:58: undefined reference to `_isatty'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-lseekr.o): In function `_lseek_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/lseekr.c:58: undefined reference to `_lseek'
/usr/lib/gcc/arm-none-eabi/4.8/../../../arm-none-eabi/lib/libc.a(lib_a-readr.o): In function `_read_r':
/home/tin/projects/debian/arm-toolchain/collab-maint/newlib/build/arm-none-eabi/newlib/libc/reent/../../../../../newlib/libc/reent/readr.c:58: undefined reference to `_read'
collect2: error: ld returned 1 exit status
make: *** [test] Error 1
18:18:55 Build Finished (took 564ms)`
I can't seem to find anyhting that works to remove these errors. I would greatly appreciate any guidence I can get on this. I'm using Debian 8.1.0 and it is up to date.
I figured this out and my mistake was to use the wrong toolchain...
Linaro makes a toolchain for the hard float arm architecture.
Simply get the linked archive, extract it, and point eclipse in the right direction. I've now got eclipse to proerly build programs for the beaglebone. I've also got eclipse to properly connect to the remote application on the BBB.
Cheers,
I am installing Redmine and I am getting crazy because of a rake problem. In particular, in order to perform a bundle install for the different Ruby's plugins, I have been asked to install xapian-full-alaveteli, v 1.2.9.5.
The problem is that I get the following error:
Building native extensions. This could take a while...
ERROR: Error installing xapian-full-alaveteli:
ERROR: Failed to build gem native extension.
/home/redmine/.rvm/rubies/ruby-2.2.0/bin/ruby -rubygems /home/redmine/.rvm/rubies/ruby-2.2.0/lib/ruby/gems/2.2.0/gems/rake-10.4.2/bin/rake RUBYARCHDIR=/home/redmine/.rvm/gems/ruby-2.2.0/extensions/x86_64-linux/2.2.0/xapian-full-alaveteli-1.2.9.5 RUBYLIBDIR=/home/redmine/.rvm/gems/ruby-2.2.0/extensions/x86_64-linux/2.2.0/xapian-full-alaveteli-1.2.9.5
rake aborted!
NameError: uninitialized constant Config
/home/redmine/.rvm/gems/ruby-2.2.0/gems/xapian-full-alaveteli-1.2.9.5/Rakefile:2:in `<top (required)>'
(See full trace by running task with --trace)
rake failed, exit code 1
Gem files will remain installed in /home/redmine/.rvm/gems/ruby-2.2.0/gems/xapian-full-alaveteli-1.2.9.5 for inspection.
Results logged to /home/redmine/.rvm/gems/ruby-2.2.0/extensions/x86_64-linux/2.2.0/xapian-full-alaveteli-1.2.9.5/gem_make.out
I've tried editing by hand the rakefile and removing the line that causes troubles, but it magically reappears. The documentation about the use of rake/gem is, imho, at least vague, therefore I am totally stuck -- with a server that was supposed to be in production two days ago...
Summary
Obsolete calls to Config can cause the error. Try changing
Config::CONFIG ====> RbConfig::CONFIG
In detail
Running a Gem's rakefile caused the error: uninitialized constant Config.
Googling suggests Config is obsolete and to replace it with RbConfig. RbConfig is in the latest Ruby though the document is blank and I cannot find a Config in Ruby.
Fixes replace Config with RbConfig: gettalong/kramdown and thoughtbot/cocaine. Which also worked in my case.
Conclusion
Replace Config::CONFIG with RbConfig::CONFIG
Anyone tried to install papi(performance API) version 5.1.0 on the mac os 10.8 ? I am getting following errors on the make command.
zero_attach.c: In function ‘main’:
zero_attach.c:84: error: ‘PTRACE_ATTACH’ undeclared (first use in this function)
zero_attach.c:84: error: (Each undeclared identifier is reported only once
zero_attach.c:84: error: for each function it appears in.)
zero_attach.c:84: warning: passing argument 4 of ‘ptrace’ makes integer from pointer without a cast
zero_attach.c:117: error: ‘PTRACE_CONT’ undeclared (first use in this function)
The INSTALL.txt doesnt say anything on the mac os. Just says it can be installed no procedure given so i tried just the standard procedure mentioned.
On the main page of papi -> platform supported, it doesnt say about anything about mac os.
Do i need to install some drivers for this ? any help will be great..
I just installed the latest version of PAPI (5.3.0) on OS X v 10.9.1.
Following the instructions in the install file did the trick too!
wget http://icl.cs.utk.edu/projects/papi/downloads/papi-5.3.0.tar.gz
tar -xvf papi-5.3.0.tar.gz
cd papi-5.3.0/src
./configure
make
The only problem I encountered was with an undefined malloc.h, this is easily
fixed by either making a dummy malloc.h stub with
touch malloc.h
or copying a good malloc.h into the src directory
cp /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/sys/malloc.h .
Then you should be fine with:
make
./run_tests.sh
make install
Happy performance counting!
p.s. I did this with gcc-4.7.3 (installed with homebrew).
Can anybody give me some hints for solving this?
I'm trying to compile "Kinect Matlab" (on Mac OS 10.7), in the compile script is the following line:
mex('-v','-L/usr/lib/','-lOpenNI',[...],Filename);
This is the full command run by mex: (1)
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2011a.app/extern/lib/maci64/mexFunction.map -o "mxNiChangeDepthViewPoint.mexmaci64" mxNiChangeDepthViewPoint.o -L/usr/lib/ -lOpenNI -L/Applications/MATLAB_R2011a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Then I'm getting the following error:
ld: library not found for -lOpenNI
collect2: ld returned 1 exit status
mex: link of ' "mxNiChangeDepthViewPoint.mexmaci64"' failed.
There is most definitely a file at /usr/lib/libOpenNI.dylib.
What kinds of things cause ld to throw this error?
What I tried:
I have tried creating a symlink called libOpenNI.so, like jmlopez suggested, no effect.
Could it be that libOpenNI is a 32bit library, and ld is not seeing it for that reason? Or would the error then be different?
Regarding the point above, it says that the build is "universal x86/x64"
Env vars:
I've tried to add the library to the environment variables using the following command, from the matlab terminal. No effect.
setenv('DYLD_LIBRARY_PATH', [getenv('DYLD_LIBRARY_PATH') ':/usr/lib/']);
In bash:
Just calling gcc as suggested here https://serverfault.com/questions/54736/how-to-check-if-a-library-is-installed gives no problems.
$ gcc -lOpenNi
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
However, if I run g++ first, then gcc as in (1), same error as before. (library not found). How come gcc can find the library, but when matlab adds the stuff in (1) it messes things up?
So, related to what is said above, I started removing all arguments from (1) until I got a different error. I removed the -Wl,-syslibroot, meaning that -syslibroot would no longer be passed to ld, this seems to have fixed it. So -syslibroot is messing up the library search directory! Now to find a way to remove this argument from the mex() call.
Did you trying adding OpenNi to your LIBRARY_PATH ?
export LIBRARY_PATH=$LIBRARY_PATH:/YOUR-PATH/OpenNi
First option: if libOpenNi isn't of the same architecture as the binary you're compiling, the whole compiler suite will likely ignore it. If you did manage to get it to link anyway, it would probably crash. Find a native 64 bit library and link against that.
Second option: I'm not 100% sure on this, but whenever I've tried doing linking on some esoteric linux projects, I start with a .a object archive in the path specified by -L. If it links, then I'll add -fPIC -shared on x86_64 to get it to compile against the shared library. I'm not sure if this will work on OSX: I've never done development on that platform yet.
BOOM! IT WORKS!
Okay, here it is:
The -Wl,-syslibroot option in the gcc call (1) is sending a -syslibroot option to the linker, and somehow that gets prepended to the library search path (even though it shouldn't according to cannot specify root sdk directory with syslibroot when linking)
So, removing this -syslibroot can solve our problem, this can be done in mexopts.sh. Copying matlab's version from the default location:
cp /Applications/MATLAB_R2011a.app/bin/mexopts.sh ~/.matlab/R2011a/
And then changing this line (201):
LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch $ARCHS -Wl,-syslibroot,$SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"
Removing the -Wl,-syslibroot,$SDKROOT argument.
Additionally, I could remove the -L/usr/lib argument from the call to mex, making it simply:
mex('-v','-lOpenNI',['-I' OpenNiPathInclude],Filename);