I've been spending a couple of days trying to set up my project in Code::Blocks on a Macbook pro (2006) with OSX 10.8.1 (I got it for free!).
After installing Xcode, command line tools, and then restarting I got the basic gcc support (will uninstall Xcode and then just use cmd line tools when I get things working). Then I proceeded to cmake and make install GLEW, GLFW3 and GLM (GLM only needed make install). I then rebootet once more to get things mostly working, I'm down to four errors, and these come from the func_trigonometric.inl file that GLM uses. The build message is as follows:
/usr/local/includ... 165 current parser token 'if'
/usr/local/includ... 37 parsing namespace 'glm'
/usr/local/includ... 160 parsing function body 'tanh'
/usr/local/includ... 160 in compound statement ('{}')
note: diagnostic msg: Error generating preprocessed source(s).
I'm not sure where to go from here.
EDIT:
I tried to install GLM the normal way with just dragging the folder to the location it should be in (include), the error still persists, I really need help with getting rid of this error.
I found out what was causing the errors, the version of GLM I was using was too new for OSX 8.1.1
Changing out GLM from version 9.6 to version 9.4 fixed the errors.
Related
I am trying to run an example from the plexe-veins folder on my Mac OS High Sierra system, to my knowledge I have installed all necessary libs.
The only problem I have is with installing the omnetpp__0.7-1.tar.gz file. Some research online leads me to believe the version of R on my computer is unable to compile the file since the file is an older version. I have tried installing older versions but failed because of compatibility issues with my OS. I am at a complete dead-end with regards to that.
When I run the platooning example, the GUI opens up of and I am able to run the simulation for a few seconds until I get the error:
(omnetpp::cDoubleParImpl)simulationDuration: Cannot cast from type
double to integer -- in module (SimplePlatooningApp)
scenario.node[0].appl (id=11), at t=1.01s, event #204 TRAPPING on the
exception above, due to a debug-on-errors=true configuration option.
Is your debugger ready? ./run: line 2: 90810 Trace/BPT trap: 5
../../run "$#"
The version of omnet I installed is omnet++-5.4 and I also followed the procedure from the manual which includes the "./configure" and "make" commands. I run the example by entering the dir in question and run:
./run -u Cmdenv -c Sinusoidal -r 2
It appears my problem was multi-pronged. These are the steps I took to solve the problem:
I followed the suggestions offered by Julian with regards to the version of Omnet++ I installed, I downgraded to Omnet++ 5.0
I also noticed that I had a previously installed sumo (not plexe-sumo) on my system and thus it seemed to be running the simulation instead of plex-sumo. So I uninstalled it.
There also seemed to be a problem with a static declaration of 'abs'followed by a non-static declaration which caused omnetpp_0.7.1.tar.gz to fail while compiling. I solved this issue by locating the stdlib.h file in xcode.app/Contents/Developer/Toolchains/usr/include/v1 and commented out "inline _LIBCPP_INLINE_VISIBILITY" (there should be a better fix).
I appreciate the help!!!
The part of OMNeT is a casting error. This is due to OMNeT++ 5.4 which changed some internals on parameters and therefore is simply to new for Plexe 2.0. You have to use an older version like OMNeT 5.0 or 5.1 as this is what Plexe 2.0 was built upon.
Also see these posts:
Error in Veins tutorial simulation
Error while running example of the veins in the last step of the installation
Is casting possible in parameter expressions in OMNET++?
I recently moved from the SGI, Sun workstation environment to a Mac. SGI and Sun came with Fortran compilers so I have maybe 100 small f77 codes I wrote over the years for post-processing and analysis of simulated data. I was hoping to get these codes running on my iMac with gfortran. Most of these are very simple codes but I can't get them to compile and execute. I tried starting with the basics and wrote the Hello World code from a gfortran help page. My code, fortran.f is:
program helloworld
print *, "hello world"
end program helloworld
When I tried compiling this according to the example I typed:
gfortran fortran.f
But I keep getting the error message:
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
This is the same error message I get on my other codes. Can someone tell me what I'm doing wrong? I can't think of a simpler example but I can't seem to get it to work.
When it comes to macOS, I think that building form sources is the best approach you can have. You can achieve that quite easily by downloading and compiling GFortran as part of GCC directly from: https://gcc.gnu.org/wiki/GFortran
However, there are few things you have to take care of:
make sure you have XCode installed, you can get it here
XCode
XCode is free of charge
Make sure you have command line tools
You can get them either from developer.apple.com
Command Line Tools
or directly from XCode. It might be that XCode will tell you to install Command Line Tools upon first execution
In the past, running command like "svn", when Command Line Tools were not installed, also triggered the installation.
Compile GCC
> ./configure --prefix=$HOME/opt/usr/local
> make all
> make install
Alternatively, you can install using macOS package from GFortran
gfortran-6.3-Sierra.dmg
Fully working sample with Fortran based MPI code:
http://www.owsiak.org/running-open-mpi-on-macos/
If your gfortran was installed a long time ago and you have updated macOS since installing, it may need re-installing to get correctly aligned and linked with the latest macOS tools and libraries.
My advice would be to:
uninstall gfortran,
check that Xcode and its command line tools are up-to-date,
re-install gfortran.
Hints for each of those steps follow:
Note that gfortran is a part of GCC - the "GNU Compiler Collection".
If you installed gfortran via homebrew, you can remove it with:
brew rm gcc
You can update Xcode by by going to AppStore and clicking Updates at top-right.
The Xcode Command Line tools include make and git and command-line versions of the compilers. You can install/update the Xcode command line tools with:
xcode-select --install
You can install gfortran with homebrew using:
brew install gcc
When you are finished, you should make sure that your PATH includes /usr/local/bin near the start and that there are no errors when you run:
brew doctor
which is a brilliant utility that checks your homebrew configuration is correct.
All I had to do was change the path.
Initially, my PATH was something like
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin
Because of this reason, the default assembler (as) was not called which is in the /usr/bin directory.
To enable the call to the right assembler (as), I had to add /usr/bin to the PATH in front of (before) /opt/local/bin, i.e. on a Mac this can be added by editing ~/.bash_profile such that one's $PATH looks like
/usr/bin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/opt/X11/bin
Once edited, execute at your command prompt:
source /etc/bash_profile
This worked for me.
Trying
devtools::install_github("Rexamine/stringi")
and getting error:
Could not find build tools necessary to build stringi
I see several people have had this error but the solutions haven't worked for me. I reinstalled xcode because the command line tools seemed to be the problem for other people. Checked the paths for R and RStudio, I can open both fine (from the terminal as well). Don't think this is an Rtools issue but I can't figure out where the problem is. Has anyone had any luck with this particular devtools error?
Running OSX 10.11.6, RStudio Version 0.99.896, R 3.2.1 GUI 1.66 Mavericks build (6956), XCode Version 7.3.1 (7D1014).
You can try running
/usr/bin/clang --version
If command line tools are installed, this should just report the version of clang installed; otherwise, you'll be prompted to install Xcode + Command Line Tools. (This is just a simple way of ensuring command line tools indeed are installed)
If you run
devtools::install_github("Rexamine/stringi")
in a plain R console, outside of RStudio, what do you see? Can you update your post with the errors (if any) printed to the console?
You might also try updating RStudio to the preview release (https://www.rstudio.com/products/rstudio/download/preview/) to see if that helps.
It seems like this is likely a bug in RStudio's build tools detection; you might try explicitly disabling it with:
options(buildtools.check = function(action) TRUE)
This should ensure that devtools doesn't try to call RStudio's build tools detection code and just assume that everything is available.
In compiling subversion 1.8.5 on Mac OS X 10.9, I run into this problem when trying to 'make' from source code.
subversion/libsvn_subr/cmdline.c: In function 'svn_cmdline_create_auth_baton':
subversion/libsvn_subr/cmdline.c:630: error: 'SVN_AUTH_PARAM_GNOME_KEYRING_UNLOCK_PROMPT_FUNC' undeclared (first use in this function)
subversion/libsvn_subr/cmdline.c:630: error: (Each undeclared identifier is reported only once
subversion/libsvn_subr/cmdline.c:630: error: for each function it appears in.)
make: * [subversion/libsvn_subr/cmdline.lo] Error 1
I recently upgraded to Xcode 5, should Xcode 5 on OS 10.9 be running in connection with subversion 1.7 or 1.8, or it doesn't matter?
At first I thought this was a problem building the SWIG bindings. We see a very similar issue with SWIG bindings. My original answer is below with that info (leaving it since some people might find this entry when looking for that error message for that).
However, on looking more carefully at the errors I see that you're having an actual problem building Subversion itself. This is a different problem. Specifically you appear to have GNOME Keyring installed and it was detected by the configure. However, the problem is there is a mismatch between the code that enables the constant you're getting an error about (checking for platform) and the constant that enables the use of that (checking for GNOME Keyring being found).
You should be able to build if you pass --with-gnome-keyring=no to configure.
SWIG
There is a known issue with Subversion 1.8.x on OSX. SWIG bindings won't build properly with the pre-generated interfaces. If you install SWIG you can still build successfully by doing the following:
make extraclean
./autogen.sh
./configure
make
You can skip the make extraclean if you're starting with a fresh tarball. Note that extraclean will remove the config.nice file so you'll need to manually pass any options to configure again rather than using config.nice.
If you're interested in the gory details the details on how this is being fixed here:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201311.mbox/%3C528D264A.4090305%40reser.org%3E
The commit on trunk that actually fixes it is here:
http://svn.apache.org/r1543961
This fix will hopefully be included in 1.8.6 so that it isn't an issue anymore.
So this is after having dropped $30 for Mac OS 10.7 and having downloaded XCode 4.3.2. After installing the command line tools, the installed version of gcc is still 4.2.4. I need 4.7. I've installed it and set the g++ link in /usr/bin to it. But when I try to compile any program via QtCreator, I get
unrecognized command line option -Xarch_x86_64
I found this discussed in a 3-year-old bug report here, but I really couldn't follow all the different shell commands etc. and my attempt to install liblastfm failed with the same error. The comment here,
The problem is that the GCC/G++ that is normally used to compile stuff
on Macs is actually just a wrapper.
And this wrapper has Mac-Only arguments like -Xarch_x86_64, which then
get converted into the correct args.
Seems like it might be hitting the nail on the head. Aaargh! Surely there has to be some way to get around this?
I created a custom makespec - in QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs, I copied the macx-g++ folder to macx-g++47. I then removed the "include(../common/g++macx.conf)" from that and included it's contents, except for the part that generates the error (i.e. the -X... thing).
I also finished with
QMAKE_CC = gcc-mp-4.7
QMAKE_CXX = g++-mp-4.7
QMAKE_LINK = $$QMAKE_CXX
QMAKE_LINK_SHLIB = $$QMAKE_CXX
QMAKE_LINK_C = $$QMAKE_CC
QMAKE_LINK_C_SHLIB = $$QMAKE_CC
...which is similar to the spec for macx-g++42.
Now, if I add '-spec macx-g++47' to the qmake args, it works.
A lot of effort for something simple...would love to know a better way.
There are several sources for newer gcc versions for OSX. Here is a small selection:
http://hpc.sourceforge.net/ (currently gcc 4.8, previous versions might also be available)
http://gcc.gnu.org/wiki/GFortranBinaries (has gcc 4.7.0 binary installer)
I assume that you did install the command line tools from within Xcode. Apple/Xcode is not always up to date with gcc, stability is more important here than bleeding edge.