I wanted to start writing c++ code again and I just realized that the homebrew version of gcc does not compile any c++, c, or even fortran programs.
For example, I tried to compile the following simple hello_world.cpp program:
#include<iostream>
int main()
{
std::cout << "Hello World!" << std::endl;
return 0;
}
using
g++-9 hello_world.cpp
The output I get is:
FATAL:/usr/local/Cellar/cctools/855/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
I tried installing gcc#8, gcc#7, and compile but I still get the same message.
Moreover, the same error message is shown when I try to compile a hello_world.c program using gcc-9 and a hello_world.f90 program using gfortran-9.
The programs *.c and *.cpp compile fine with the clang and clang++ compilers respectively. I also learned that as is an assembler, and that gcc can output a *.s file using the flag gcc -S but I still don't understand the error message.
I think I exhausted my c++ knowledge and internet search before posting so thank you in advance!
I ended up reinstalling all packages using
brew list | xargs brew reinstall
This fixed the problem!
For anyone else who has stumbled across this problem, you do not need to reinstall all of your brew packages. The troublemaker is cctools, which is no longer in the brew formulae list. If for some reason it is still hanging around on your system, you can either
mv /usr/local/Cellar/cctools{,-backup}
to make sure it is no longer seen by the gcc tool suite installed through homebrew, or you can outright remove it
brew uninstall cctools
I opted for the first, at the moment, because I am not sure what, if anything, removal would break. Once I have confirmed that there are no ill effects caused by not having this installed, I will remove it altogether from my system. That being said, I have confirmed that simply moving the directory takes care of the
FATAL:/usr/local/Cellar/cctools/855/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
error being reported when you try and compile something with the GNU compiler on Mac OSX (in my case Catalina, but should be the same for Big Sur and Monterrey).
Related
First of all, I made a simple program to test if compiling was working properly, it is as follows:
#include <iostream>
int main() {
std::cout << "Oi!";
}
Quite simple indeed, should compile properly, right? Wrong.
I am using MinGW for Windows 10, just to let you know.
I tried compiling it using "cpp <file name>.cpp -o a.exe" and was, first time, going through with the compile, but once I tried to execute the file it would send me this:
./a.exe: line 14: namespace: command not found
./a.exe: line 20: syntax error near unexpected token `('
./a.exe: line 20: ` typedef decltype(nullptr) nullptr_t;'
Clearly something was wrong, so I searched for a solution, found out someone had a similar problem and doing a reinstall solved it, so I went to the MinGW installation manager, noticed the C++ compiler library wasn't installed and installed it. It felt I was doing alright.
I also noticed that they were using g++ instead of cpp and tried that instead, it worked properly this time, but I would like to note that I have "git bash" installed, so I assume it used "git bash" 's command and not MinGW's.
So I opened cmd and tried using cpp, once I tried executing the program cmd said that the software wasn't compatible with the version of windows being executed, that doesn't sound right. I did a verbose compile with cpp and noticed this oddity:
#include <...> search starts here:
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++/mingw32
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include/c++/backward
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/6.3.0/include-fixed
End of search list.
That doesn't follow Windows's file path standard...
Does it have anything to do with the problems I am facing? I just want things to compile! ;w;
As mentioned above, you need to use g++ to compile your code. Try the command g++ --version If you get any result that doesn't include a version number you need to install g++. Here is a guide that may be helpful.
https://techsupportwhale.com/install-gcc-compiler-on-windows/
Backstory: I started using my terminal for a lot of my school projects. I recently got familiar with it and wanted to "upgrade" by installing iTerm2 and homebrew; but before I installed the two, I was able to compile my C++ homework files "g++ filename.cpp" and run "./a.out" no problem. After installing iTerm2 and homebrew followed by xcode commandline tools I started running into this problem every time I try to compile my c++ files:
"ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libSystem.tbd' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)"
I created a simple "Hello World!" c++ and that won't even compile. I've tried everything even some posts on here. Hopefully someone has a different solution. Thank you in advance!
The code is super simple:
#include<iostream>
using namespace std;
int main() {
cout << "Hello World!" << endl;
return 0;
}
How I tried compiling it: "g++ main.cpp"
Which back then I get an a.out file but this time I get that error message shown in the picture.
I added more photos showing my g++ version and also the attempt of compiling it: "g++ -Wall -Wextra -g main.cpp -o prog.bin"
I'm also running macOS Catalina 10.15.6
Thank you in advance. I'm reading through the documentations provided rn.
g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
enter image description here
UPDATE:
I uninstalled and reinstalled Xcode CommandLineTools and homebrew; however, this time I did not update the CommandLineTools to beta 5 like I did before.
Now I'm able to compile and run my school assignments. Not an ideal solution but I'm back to working on my school assignments peacefully. Thank you all for the help!! I guess installing the beta CommandLineTools is not such a great idea.
I have a simple helloworld.cpp to instrument with Score-P or Vampirtrace.
Installation of the performance/ tracing tools works fine. After compiling and running:
# score-p
scorep-g++ helloworld.cpp -o hello
export SCOREP_ENABLE_TRACING=true
export SCOREP_ENABLE_PROFILING=true
# vampirtrace
vtcxx -DVTRACE helloworld.cpp -o hello
# run
./hello
The created OTF files (OTF for vampirtrace/ OTF2 for Score-P) are more or less empty (no timeline data). I'm using Vampir to visualize the data.
More details:
I'm testing on Mac OS X (g++-8) and Xubuntu (g++-7; VirtualBox).
For Mac OS X I have installed brew install gcc.
For the instrumented Score-P version I also got a warning
[Score-P] src/measurement/profiling/scorep_profile_callpath.c:206: Warning: Master thread contains no regions.
but I can't find related issues/ help.
I also installed TAU and PDT for Vampirtrace, but nothing changed. By the way manual instrumentation works for Vampirtrace:
#include "vt_user.h"
...
VT_TRACER("name");
For Vampirtrace I also tested OpenMP instrumentation and this was working, but only that (no application tracing around).
For both environments I did not install Open MPI.
It would be great, if somebody has similar issues and could help.
PS: Later, I want to instrument an application with Poco::Threads. I only read about partial support for POSIX Threads.
Update
The problem is g++. I tried the same instrumentation with Intel icc and it worked.
The missing instrumentation with g++ is also possible with icc, if you add the parameter --nocompiler like
score-p --nocompiler icc helloworld.cpp -o hello
Update
I had to install missing packages. There are logging outputs for ./configure with hints. One of the following package solved it:
apt-get install llvm libwrap0-dev libclang-dev gcc-7-plugin-dev
When trying to compile Fortran using PGI on Mac OS X Sierra, I get the error
ld: file not found: /usr/lib/crt1.o
I found a workaround for older Mac OS X versions (http://www.pgroup.com/userforum/viewtopic.php?t=4578)
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
However, with Sierra, System Integrity Protection prevents writing in /usr/bin. How can I solve this problem?
I tried linking into /usr/local/bin/ (which is permitted), but then, how can I make sure the compiler searches for library in that path?
Installing just the Command Line Tools for Mac OS X solved the problem. Do this in your terminal:
xcode-select --install
Installing Lazarus on MacOS X :
worked for me
http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29
Solution for command line programs:
The correct answer for me was as explained in this link:
https://medium.com/#kviat/free-pascal-3-0-2-linking-on-macos-sierra-c40706e86fda
After some googling I realized that most libraries were removed from
/usr/lib in macOS Sierra. However this case is handled in FPC, so we
just need to set internal compiler variable MacOSXVersionMin to 10.8
(or later). There is no standard compiler option for it, but after
some search in source code I found the solution: set the environment
variable MACOSX_DEPLOYMENT_TARGET:
You should give the deployment target of MacOS:
MACOSX_DEPLOYMENT_TARGET= XX.XX #for instance 10.15
Solution for generally:
Linking the necessary file to /usr/bin/crt* . As already stated, this linking will be prohibited by MacOs beginning from 10.10. But there is still a way to accomplish this linking procedure and it solves the problem.
1) Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot Mac OS X into Recovery Mode
2) When the “MacOS Utilities” / “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3) Type the following command into the terminal then hit return:
csrutil disable; reboot
4) When you come back, run the command sudo mount -uw /
5) Just run the linking code you want to:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
sources: http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/
https://www.reddit.com/r/MacOS/comments/caiue5/macos_catalina_readonly_file_system_with_sip/
In my case the problem was actually an error on the PGI installation side. PGI seems to be well aware that newer versions of macOS do not have the /usr/lib/crt1.o and that you can't create files there anymore. But it is possible to setup correct environment variables for the PGI compilers and then the linker should use the correct path to the crt1.o.
This configuration should be done automatically during the installation of the PGI compiler suite by running the makelocalrc command and should generate the file /opt/pgi/osx86-64/$PGIVER/bin/localrc. But in my case this step failed silently.
Reasons for failure seem to be:
license agreement for XCode not (yet) accepted, although this error should leave you with a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error, containing some details
XCode version not supported, which seems to leave you with nothing. This is what I got when I ran the makelocalrc script manually:
makelocalrc -x /opt/pgi/osx86-64/19.10
Error: Unsupported XCode version 11
In my case (PGI 19.10, macOS 10.15, XCode 11.2.1) I manually patched the /opt/pgi/osx86-64/19.10/bin/makelocalrc to not error out on XCode 11:
if test $xcodever -gt 11 ; then # <-- was "-gt 10"!
echo " Error: Unsupported XCode version " $xcodever
exit -1
fi
and then re-ran the script after which compilation with PGI compilers (both pgcc and pgfortran) worked:
sudo /opt/pgi/osx86-64/2019/bin/makelocalrc -x /opt/pgi/osx86-64/19.10
Your case may vary, but you might want to check for a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error or the /opt/pgi/osx86-64/$PGIVER/bin/localrc itself and try to manually (re-) generate it if it is not there or if you upgraded XCode/macOS since the installation of the PGI compilers.
I have an issue compiling amqpcpp on a centos virtual machine, But it works fine on my iMac.
when I am running make I get this error:
g++ -Wall -I/usr/local/include -L/usr/local/lib -Iinclude/ -c -o src/AMQPExchange.o
src/AMQPExchange.cpp src/AMQPExchange.cpp: In member function ‘void
AMQPExchange::sendDeclareCommand()’: src/AMQPExchange.cpp:73: error: cannot convert ‘amqp_table_t’
to ‘amqp_boolean_t’ for argument ‘7’ to ‘amqp_exchange_declare_ok_t*
amqp_exchange_declare(amqp_connection_state_t_*, amqp_channel_t,
amqp_bytes_t, amqp_bytes_t, amqp_boolean_t, amqp_boolean_t, amqp_boolean_t, amqp_boolean_t,
amqp_table_t)’
make: *** [src/AMQPExchange.o] Error 1
Github Issue Url
g++ version
g++ --version
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)
Unfortunately, I do not know enough of C++ or make yet to fully understand the issue. It seems that the compiler is complaining about a type cast style conversion in the code, which is confusing as it works fine on the mac.
Any ideas?
Thanks
Edit: I have downloaded the latest version of amqpcpp on both machines and re-compiled them, with the same results.
Edit 2: I realised that I installed librabbitmq-c on my mac a couple of months ago, I've just updated it to the latest version and it compains of a similar error to the centos machine, It appears that amqpcpp is not compatible with the latest changes to the librabbitmq codebase. It seems that this particular commit causes the issue:
Commit 2340b039f029f3b8101a164d3bcd547be1106906
I am going to try and update the AmqpCpp codebase to apply a fix, will post a link to pull request if it works. Otherwise, using an earlier commit when checking out the code should allow it to work.
Thanks
I finally found the cause and 2 (temporary) resolutions.
Option One.. pull the librabbitmq code before the breaking changes:
$ git clone https://github.com/alanxz/rabbitmq-c
$ cd rabbitmq-c/
$ git checkout e1746f92585d59364fc48b6305ce25d7fc86c2a4
And then compile as normal. I have tested this method and it works fine for me. Keep an eye out for future update on the AMQPCpp github page so that you know when its safe to update to the latest version.
Option Two .. Update the AMQPCPP code:
AMQPExchange.cpp:
Un-comment line 69 so that it reads:
amqp_boolean_t autodelete = (parms & AMQP_AUTODELETE) ? 1:0;
Change Line 73 so that it reads:
amqp_exchange_declare(*cnn, (amqp_channel_t) 1, exchange, exchangetype, passive, durable, autodelete, 0, args );
Then you should be able to compile without an error. BEWARE: there are more changes in the librabbitmq code than just this function, which is why I stated this is a temporary fix. The AMQPCpp project will need to be updated properly to reflect the most recent changes. This fix works for what I need it to, You may find some other functionality is broken.
I personally decided to use Option One and it's now working as expected.
Thanks