Any help on my problem is appreciated...
I'm trying to run this program located in the sparsenet.tar.gz file at http://redwood.berkeley.edu/bruno/sparsenet/
There is a README that I try to follow but I can't seem to compile my cgf.c...
The first step I assume I did correctly (I'm pretty sure I am able to compile the libnrfopt.a).
But when I type "make" in the sparsenet directory, it says:
new-host-2:sparsenet user123$ make
mex -I./nrf -L./nrf -lnrfopt cgf.c
make: mex: No such file or directory
make: * [cgf.mexmaci64] Error 1
I assume it means my terminal isn't recognizing Mex, can anyone point me to how that works? (Before you tell me I haven't done enough searching, I have...I just cant seem to find anything relevant...I have my command line options in Xcode running, GCC works, Mex -setup works)
By the way, I'm doing this in Terminal, not inside MATLAB. Doing it inside matlab by directly using Mex doesn't work for me either.
Also I've changed the mex extensions to a variety of choices including mexmac, mexmaci64, etc.
Thanks in advance!!
I was able to get it to work (R2012b, OS X 10.8.4). The code is old though, looking at the dates on some of the files so I'm not surprised that you had issues. Following the README, first I performed make libnrfopt.a in the nrf folder using Terminal. Then, in the Matlab command window I used cd to move to the sparsenet folder and executed (the same command that that produced an error when you ran make from the Terminal):
mex -I./nrf -L./nrf -lnrfopt cgf.c
From here I was able to follow the README and run the example.
By the way, if you've never run mex in Matlab before, you may need to run mex -setup first. As you mentioned Xcode, I assume that you have the compiler you need.
Ok I figured it out, in the makefile, I just needed to change the Mex = mex to the directory of mex.exec in my Matlab folder and change mext to maci64
Yes I did put:
MEX = /Applications/MATLAB_R2012a.app/bin/mex
MEXT = mexmaci64
In case your mex setup is not alright, check mexopts.sh file and change
to gcc-4.2 and g++-4.2 in the CC options. I had these compilers. Other compilers
should work too.
In case more problems persist check out this: http://www.mathworks.nl/support/solutions/en/data/1-FR6LXJ/
Related
I'm trying to build binutils-2.39 and gcc-7.5.0 following the instruction here:
https://www.nongnu.org/avr-libc/user-manual/install_tools.html
These instructions have worked for me in the past. However with the above versions at least I get a non-working compiler. It fails like this:
$ avr-gcc test.c -o test
/home/tuser/local/avr/lib/gcc/avr/7.5.0/../../../../avr/bin/ld: cannot find -lm: No such file or directory
/home/tuser/local/avr/lib/gcc/avr/7.5.0/../../../../avr/bin/ld: cannot find -lc: No such file or directory
I haven't had much luck with google for these errors. Ideas?
It looks like my mistake was expecting the link step of compilation to work before avr-libc was installed. The above "cannot find" messages apparently refer to components normally provided by avr-libc.
Since the compile and link of a simple test file didn't work, I didn't think building avr-libc would either. But it did, and after installation
then building of the original (basically empty) test program did also.
This probably should have been obvious but something pathological in my normal (non-test user) setup is causing the ./configure of avr-libc to fail in a way that let me astray. Sorry if this cost anyone any time.
My specifications are up to date (OS X El Capitan, 10.11). Here are details on what I've tried so far.
I've followed the (Terminal) installation steps included in the wxWidgets download:
mkdir build-cocoa-debug
cd build-cocoa-debug
../configure --enable-debug
make
cd samples; make;cd ..
cd demos; make;cd ..
Then, I followed the wxWidgets wiki guide for creating Xcode projects.
Of course, there were plenty of compilation errors. After taking care of an incorrectly typed include, there were still issues. For the most part, they were undeclared identifiers and incomplete types, but my attention went to one in particular:
"No Target! You should use wx-config program for compilation flags!"
After researching, I believe I need to use wx-config to find what flags to input into the "Other Linker Flags" option in Xcode. However, I can't seem to utilize wx-config in Terminal.
I'm not sure if I'm dealing with the core issue. If I am, how do I use wx-config? And if I'm not, please steer me in the right direction.
Thank you.
*** EDIT: ***
I've used wx-config to find which flags I needed to input into "Other Linker Flags" and "Preprocessor Macros" in Xcode. This significantly reduced the amount of errors and warnings that I was facing.
Unfortunately, these new errors are esoteric to me:
Error/Warning Log
How do I remove these errors so I can run this project?
I'm finally able to compile and run wxWidgets programs using Xcode 7. I've found and followed this awesome guide (of which step 3 seems to now be irrelevant).
In case the link breaks, here is a summary of the steps that helped me:
* * * * * *
Open Terminal and install Homebrew by inputting:
ruby -e "$(curl -fsSkL raw.github.com/mxcl/homebrew/go)"
Then, input:
brew install wxmac
Open Xcode and create a Command Line Tool C++ project.
Back in Terminal, input:
wx-config --libs
Once inputted, copy everything outputted by the Terminal and place it into Other Linker Flags (found in Build Settings of your Xcode project).
At Terminal, input:
wx-config -–cxxflags
Again, copy everything outputted except this time place it into Other C++ Flags (do not erase what is currently in that section).
Then, of course don't forget to include wx/wx.h and don't forget to have at least an empty main function if you want it to run.
* * * * * *
I'm not at a place where I can create Cocoa projects/products, but that's totally fine. I simply wanted a canvas to familiarize myself with the wxWidgets library.
I hope this post will be helpful to others.
Arman,
First couple of questions:
What OS are you trying to compile?
What is your requirements for the minimal OSX version?
I presume you are trying to compile the latest Git HEAD. Please correct me if its not the case.
Now, couple of recommendations:
Try to run "../configure --help" and see at all the different options you can set.
Try to run "../configure --enable-debug --with-mac-osx-version-min=10.x --with-cocoa". This command has to be run after removing the build directory completely and pretending you are starting over.
Try to open the "minimal.xcode" project in the samples/minimnal directory, add the minimal.cpp file to it and compile. If it compiles and runs fine, then you made a mistake setting up the project of your own.
Let us know how it goes.
On a Windows system, currently I'm trying a waf configure on a directory of code, and it spits out the error "could not configure a C compiler."
Now, I'm 100% certain that I have gcc and g++ installed and in my path because when I type gcc --version, it gives me the current version information. (I'm using mingw and the gcc/g++ are in the /bin subdirectory).
In the author's code directory there is a wscript file which looks like
C_COMPILER = 'gcc-4.7'
CPLUSPLUS_COMPILER = 'g++-4.7'
Now, I have tried changing the strings to simply gcc as well as gcc-4.8.1 (since my current version is 4.8.1), but it still says could not configure compiler.
I tried reading one solution on this same site that looks related, but the solution was on ubuntu and trying to work through those commands didn't help
could not configure a c compiler
I'm at the end of my common sense here after making sure I have gcc and g++ installed, trying different strings in the wscript file trying to get it to recognize I have them installed, and could use some help, thanks.
Edit: I've now tried simply deleting the lines in the wscript file where it changes the compiler name, and suddenly waf configure goes through, but the waf build fails saying things like it can't find really basic things like include vector. The output says it's defaulting to msvs (microsoft visual studio) whereas the author says gcc/g++ is needed; maybe this is the issue but how do I get waf configure/build to use g++/gcc as default?
I have been using MinGW and the GNU Fortran compiler for a while in order to compile Fortran programs on Windows, which has always been a successful method. However, I have been getting the following error for the past 4 days:
The application was unable to start correctly (0xc000007b). Click OK to close the application.
The error only happens when running applications that I wrote myself, and that I compiled using the MinGW/gfortran combo. When compiling using Visual Studio and iFort, I have no problem running the applications. The error seems retroactive: applications that were compiled using gfortran a long time ago and ran perfectly until now also break, even though I didn't recompile them. This leads me to think that it is a dynamic library problem. Online searches show that it probably is a compatibility problem between a 64-bit dll and a 32-bit application
I am using Windows 7. One of the latest things I remember doing before starting to get the problem was trying to update MinGW ; I used the mingw-get update and mingw-get upgrade command lines.
After looking around online, I have tried the following fixes:
- reinstalled the Visual C++ Runtime Environment
- reinstalled the .NET framework
- downloaded and replaced a bunch of .dlls like mscvr100.dll, mscvr100d.dll, etc...
- uninstalled and reinstalled MinGW in order to make sure I had the latest gcc version
- run Dependency Walker on a simple application ("Hello World!" type program)
Dependency Walker tells me that a number of .dlls cannot be found (full list: API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL, API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL, API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL, DCOMP.DLL, GPSVC.DLL, IESHIMS.DLL).
It also highlights in red the libquadmath-0.dll (on which libgfortran-3.dll seems to depend). Indeed, it seems that libquadmath-0.dll is a 64-bit DLL in the middle of a 32-bit program. When opening said .dll with Dependency Walker, I can see that all the modules in this library are x86 except the library itself which is x64 (CPU column of DW). I am not exactly sure how this is possible / how to fix it. The library is found in the Python/Anaconda folder (I installed Python and Anaconda a few weeks ago, the problem did NOT appear at that time).
If anybody has an idea of how to get my environment to work again without reinstalling Windows, I would greatly appreciate it! Thanks!!
I had a similar problem. Looking at Dependency Walker I wasn't loading API-MS-WIN-CORE entries. However, when I went to edit my path it turned out that by bin folder wasn't on the path. Adding, in my case the mingw64 bin folder to the path fixed this issue for me. I only mention the API-MS-WIN-CORE entries since I thought it might be the problem, but in reality it wasn't causing my issue.
I was getting this same error code, and used Dependency Walker to discover that, in my case, the 64-bit version of libwinpthread-1.dll was not being found. This helped me resolve my issue.
So, the solution is to determine the missing dll, track it down on your system and reference its location in your path variable, or find out how to install it if you don't have it.
That said, I also came across the following caveat that's important to know about when using Dependency Walker. It's currently out of date and will actually show false results for WIN-CORE dlls: https://stackoverflow.com/a/36244483/4438237
To work around this, there's a newer program called Dependencies by lucasg, that properly interprets these and won't mistakenly tell you about these falsely missing dlls.
I was getting same Error, as mentioned in above answers the problem is "path not being set" aside from setting path you can alternatively Do this; if u don't want to set the path for some reason:
Open CMD
cd C:\MinGW\bin to navigate to the bin directory of mingw
now u can compile the code as following Gcc (dir of ur .c file) -o (ur output dir) for ex : gcc I:\dir\Hello.c -o I:\dir\output.exe
alternatively if u want to automate the process u can make a batch file to automatically do it for you.
here's the batch file if anyone needs it
#echo off
C:
cd \MinGW\bin\
gcc I:\dir\*.c -o "I:\dir\Output.exe" Rem Replace "dir" with your own directory and * with ur own FileName!
pause
I had a similar error but over came it by editing my environment variables.
I had g77 as part of my path variables and by removing it and leaving gfortran alone, the error disappeared
I was on Windows 10 using cmake-gui to generate a MinGW-w64 project and meet same problem.
My solution: go to start windows, search and open MinGW-w64 terminal, then in terminal call cmake with specifiying cmake options.
Yes the old posts got it right. It is the environmental parameters messed up. I got the same error. It is solved by putting the msys64 path to the first:
Path=c:\msys64\mingw64\bin;%PATH%
The msys64 path was the last, now it is the first. Type it once at the command line after Windows started, or edit the Path environmental parameter if you have the admin right.
I'm trying to build a cross-compiler (x86->64) on my windows system, with the aim of targetting windows 64, however my software currently relies on open source libraries which also have open source dependencies for which there are no prebuilt binaries available with which I can compile. This means that if I want the 64 bit versions I need to compile them.
I've installed MSYS and mingw, I'm also in the process of adding mingw-w64 to the mix so that I can finally compile the libraries in 64 bit form for use with my software. I'm following the steps as closely as I can using these instructions and in the order listed on that page, I'm currently at the step titled "Building the GCC core cross-compiler(s)", but when I try to compile with the line:
$ ../gcc-4.6.1/configure --target=x86_64-w64-mingw32 --enable-targets=all && make -j 6 all-gcc && make -j 6 install-gcc
I get the output pasted here. I should note that I of course snipped the previously executed commands and that last command was the last one listed before all the errors were displayed. Also, I have no idea if it's the cause of all the errors due to the '-j 6' argument, but everything prior to it at least looked successful.
What's the problem and how can I fix it?
Oh, in anticipation of one potential suggestion; no I can't just switch to cygwin.
Edit: Okay after executing them individually, here's the output of the configure command, the output produced by make all-gcc (no -j argument), and config.log. Note, I didn't run a make clean beforehand which may explain the different ending, I didn't do it in the interest of time to write this update, but I suppose I'll just make a different compile folder and re-execute it cleanly to hopefully see the same error as before while I wait for a response.
Edit 2: The make all-gcc failed again as expected, this time the output should help a little more I hope.
Thanks very much for your help.
Your config.log shows that the build process will use the binaries in x86_64-w64-mingw32/bin for stuff like ar, as etc... These are for internal compiler use only, and they should all be available in your /mingw/bin directory. I would strongly suggest asking on the mingw-w64-public mailing list for help.