I've installed Swift 5.6.1 on my Windows 10 machine, including all the necessary Visual Studio components, but I can't seem to build anything. Even just running the following set of commands in git bash results in an error:
mkdir swiftTest
cd swiftTest
swift package init --type executable
swift build
Specifically, the swift build command gives the following errors:
warning: Failed creating default cache location, Error Domain=NSCocoaErrorDomain Code=256 "(null)"
'swiftTest': error: invalidManifestFormat("Missing or empty JSON output from manifest compilation for swiftTest", diagnosticFile: nil)
The error message seems surprisingly rare -- the top google results were the source of the program that generated that error, and an unrelated error with similar wording from a ReactJS application.
Do I just have to add some flags to the swift build command, or is there something else wrong with my setup?
In my case what fixed it was invoking the command from a Visual Studio Developer Command prompt.
I am trying to compile a project using the libusb-1.0 library. When i compile from cmd with the following command
gcc -g main.c -o test.exe -lusb-1.0
my program compiles just fine. However if I try to use the Powershell window inside VSC i get this error
gcc.exe: error: .0: No such file or directory
I've run the same code from both terminals.
While I still can compile and run my code, it would be convenient if I could do it from within VSC.
How can i fix this error?
Try with (double) quotes around the -lusb-1.0 parameter.
Opening a file in simulink and running it produces the following make error:
Making simulation target "ekf_trial_sfun", ...
/Applications/MATLAB_R2013a_Student.app/bin/mex -c -O -DMATLAB_MEX_FILE -I/Applications/MATLAB_R2013a_Student.app/stateflow/c/mex/include -I/Applications/MATLAB_R2013a_Student.app/stateflow/c/debugger/include ekf_trial_sfun.c
xcodebuild: error: SDK "macosx10.7" cannot be located.
xcrun: error: unable to find utility "clang", not a developer tool or in PATH
mex: compile of ' "ekf_trial_sfun.c"' failed.
gmake: *** [ekf_trial_sfun.o] Error 1
I have clang on my computer. Do I need to open up the mex .sh file and rename all the old operating system refences (10.6) to 10.10.4? I tried doing a find and replace and that didn't work.
The file was given to me by another engineer
I also get the warning: Some of the issues encountered during model compilation may be because this model was created in a previous release.
I am getting the following error when trying to compile openCV with the matlab module.
I just run $make in the realse folder that I created like in the tutorial from opencv.org
[ 98%] Compiling Matlab source files. This could take a while...
CMake Error at /home/alex/Downloads/opencv-master/modules/matlab/compile.cmake:47 (message):
Failed to compile drawChessboardCorners: /usr/bin/ld: cannot find
-lopencv_core
/usr/bin/ld: cannot find -lopencv_imgproc
(Removed alot of lines with lib files here)
collect2: error: ld returned 1 exit status
mex: link of ' "drawChessboardCorners.mexa64"' failed.
How do I fix the link error? Does it have something to do with matlab?
MATLAB 2013a
Ubuntu 13.10
I don't think this is related to MATLAB. The:
/usr/bin/ld: cannot find
points probably to a missing path for the opencv_core library that the linker cannot find during compilation. See: usr/bin/ld: cannot find -l<nameOfTheLibrary>
If you are building manually you could add an -L option, e.g.,
-L<path_to_opencv_core> before the -lopencv_core or -lopencv_imgproc
to the command line build command. If you are using a CMake file, there may be an ${OPENCV_LIB_INSTALL_PATH} (or something similar) that you can set, e.g., using ccmake.
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);