No matter how hard I google, I can't seem to find a (relatively) easy-to-follow instruction on how to install the GNU Assembler on a mac.
I know I can use gcc -c (Apple Clang on a Mac) to assemble .s / .S files, but I want to use actual GNU Binutils as.
The GNU assembler cannot (yet) be used to create native object files (of Mach-O format). But you can of course use it to cross-assemble for some non-native object format, if that is what you want.
yasm works on Mac OSX (I got it from Homebrew), and it has a GNU as syntax parser which can be enabled with -p gas (it may be necessary to also add -r gas). It is not 100% complete, but it covers mostly everything. It can output to a variety of object formats (if cross-compiling is necessary), and in my opinion it's pretty cool. You can also use NASM syntax (which is completely supported) using -p nasm (again, -r nasm may be necessary).
Sorry about necroposting, but this is a still-relevant question and I believe that it needs an acceptable answer.
The gnu assembler is already installed on your mac (assuming that you installed the dev tools package). If you want to avoid XCode, you can invoke it from the command line with as, or with the preprocessor by using gcc yourfile.s $(OPTIONS).
Edit: as now points to the clang assembler; at the time this answer was written it pointed to (Apple's build of) the GNU assembler.
Maybe as instead of gas ? If you want to have gas as command invoke this: echo "alias gas=as" >> $HOME/.profile
It was installed on my Mac Lion when i opened the terminal and typed it. It might have been because of MacPorts and/or XCode as mentioned in the comments of a previous answer.
Related
My question is how can I recompile Crypto++ with GCC-4.8 in FreeBSD 9.2?
I'm having the following error, and I noticed that recompiling CrypTopp would solve the problem.
undefined reference to `CryptoPP::AlignedDeallocate(void*)'
Thanks!
My question is how can I recompile Crypto++ with GCC-4.8 in FreeBSD 9.2?
There's usually 3 or 4 things to be mindful of with later versions of GCC and the BSDs. They are enumerated below. If you have a specific problem, then you should ask.
-----
First, install gmake and use it instead of the BSD's anemic make. So you would compile with something like:
cd cryptopp
gmake GNUmakefile
I think other dependencies include gettext and libiconv.
-----
Second, the Crypto++ makefile sometimes blows away your choice of CXX and maybe LD. Open the GNUmakefile and hard code them to want you want if its occurring.
-----
Third, Crypto++ has some bug fixes for dependent name lookups. This only affects later versions of GCC, like 4.7 or 4.8 and above. See, for example, Unable to make on MingW due to unrecognized option.
So you should be using Crypto++ from SVN, and not the ZIP file from the website. See SVN on the Crypto++ wiki on how to check it out.
-----
Fourth, install Crypto++ into /usr/local, and not /usr. For some reason, one of the BSDs (OpenBSD) treat everything in /usr/include as a C file, and does not honor a C++ file. It will lead to unexplained compile failures. You can read about it on the Crypto++ wiki: Linux and OpenBSD.
So your install would look like:
sudo gmake install PREFIX=/usr/local
-----
There should also be a port available. You should try and use it if its available. For example its available as cryptopp-5.6.3-2 under FreeBSD. OpenBSD has a patch at Fix: net/synergy, so its probably available in their ports tree, too.
-----
Finally, there is a Crypto++ wiki page covering Linux and the BSDs at Linux and BSD. Its basically everything I know about building and running Crypto++ on *nix variants. If you are a die hard BSD guy, then my apologies for lumping Linux and BSD together on one page.
It seems that information about using the two together is not easy to come by. When trying to make I get some fun errors. I was wondering if my version of gcc (4.7) won't cut it or I'm lacking a dependency.
I included...
GCC
GNU Make
GNU Bison
GNU gettext
GNU binutils
Flex
Am doubtful about but am beginning to wonder if it matters
libdevmapper
The error that occurs in Cygwin x86 - Possibly GCC 4.7 related?
../grub-2.00/grub-core/lib/xzembed/xz_dec_lzma2.c:534:29: error: always_inline function might not be inlinable [-Werror=attributes]
FYI, the problem appears to have something to do with header sizes being larger than expected. The issue is related to this problem:
http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00342.html
Do this:
export TARGET_CFLAGS="-Qn"
...and rebuild from a fresh grub-2.00 source directory. That should fix things up.
I have Lion 10.7.3 with the Command-line tool installed. I wanted to experiment with C++11, so I used homebrew to install GCC 4.7 as documented here.
How can I now upgrade the /usr/bin/g++ to be the one installed by Homebrew? Is it as simple as symlinking it? I just want to double check and make sure. Thanks!
First, are you sure you need g++ 4.7? As you can see from the C++11 implementation status page, recent versions of clang support most of C++11 too. Of course there are still things that g++ handles and clang doesn't, but there are also still things that clang supports and g++ doesn't. And, more importantly, you already have a recent version of clang, from Apple, configured and ready to go, as your default compiler. Plus, g++ after 4.2 doesn't support Mac extensions like, say, -arch, which means you can't use it to build a whole lot of third-party software (because most configure scripts assume that if you're on a Mac, your compiler supports Mac extensions).
But if you want g++ 4.7, you can do it. Just not by trying to replace /usr/bin/g++ with a different version. Never replace anything in /usr/bin (or /System) with non-Apple stuff except in a few very rare cases (when you have a strong reassurance from someone who knows what they're talking about).
A better thing to do is to just install another compiler in parallel. Just let Homebrew install its favorite way (so it installs into some prefix like /usr/local/Cellar/gcc/4.7, then symlinks all the appropriate stuff into /usr/local/bin, etc.), and use it that way.
When compiling your code, instead of writing g++, write /usr/local/bin/g++, or g++-4.7.
If you get tired of doing that, put /usr/local/bin higher on your PATH that /usr/bin, or create a shell alias, or stick it in the environment variable CXX and write $CXX instead of g++.
If you're using a GUI IDE, you should be able to configure it to use your compiler by setting the path to it somewhere. (Unless you're using Xcode, which you can only configure to work with Apple-tested compilers.)
This is all you need for experimenting with your own code. If you want to compile third-party applications with this compiler, that may be a bit more complicated. You don't often actually compile each source file and link the result together; you just do configure && make and let them do the heavy lifting for you.
Fortunately, most packages will respect the standard environment variables, especially CXX for specifying a default C++ compiler and CC for a default C compiler. (That's why I suggested the name CXX above.)
Just remember that, again, g++ 4.7 doesn't support Mac extensions, so if you're not prepared to debug a bunch of autoconf-based configure scripts complaining that your compiler can't generate code because it assumed it could throw -arch x86_64 at any compiler on a Mac, etc., don't do this.
I am trying to compile a program that uses the pclmulqdq instruction present in new Intel processors. I've installed GCC 4.6 using macports but when I compile my program (which uses the intrinsic _mm_clmulepi64_si128), I get
/var/folders/ps/sfjmtgx5771_qbqnh4c9xclr0000gn/T//ccEAWWhd.s:16:no such
instruction: `pclmulqdq $0, %xmm0,%xmm1'
It seems that GCC is able to generate the correct assembly code from the instrinsic, but the assembler does not recognize the instruction.
I've installed binutils using macports, but the problem persists. How do I know which assembler gcc is using? The XCode assembler probably does not support it, but the binutils assembler should.
A simpler solution that fixed this problem for me was adding -Wa,-q to the compiler flags. From the man pages for as (version 1.38):
-q
Use the clang(1) integrated assembler instead of the GNU based system assembler.
The -Wa part passes it from the compiler driver to the assembler, much like -Wl passes arguments to the linker.
The GNU assembler (GAS) is not supported in Mac OS X.
In order to use AVX, I had to:
Install GCC using MacPorts;
Replace the native OS X assembler (/usr/bin/as) by a script which calls the clang assembler.
Compile the program with the installed GCC (e.g. gcc-mp-4.7)
The strange thing is that while the clang assembler supports AVX, the clang compiler does not recognize the AVX instrinsics, forcing the ugly workaround above.
The built in version of as is outdated. (In OS X 10.8.3)
/usr/libexec/as/x86_64/as -v
Apple Inc version cctools-839, GNU assembler version 1.38
There does not seem to exist a version of gas for OS X. (See:
Installing GNU Assembler in OSX)
Using the clang assembler via a script hack (as pointed out by Conrado PLG) is one workaround. However, it does require administrator privileges and overwrites OS X-bundled executables, causing a risk of it being overwritten by a new (yet possibly outdated) version of as bundled with a future version of OS X.
Is there then a better workaround?
As noted on Why does cross gcc invoke native 'as'? it seems to be possible to specify which "as"-executable and flags to use (using "-specs=..."). A cleaner workaround to the problem seems to be to pass the correct "-specs" flags to invoke the clang assembler. This does not require admin privileges and does not risk being broken by an OS X update. The exact details of how to perform this remains to be found out (anyone?).
If this workaround becomes trouble-free and transparent enough, it may be warranted to use those settings as a default (or at least variant) for the macport gcc (so that it supports "-march=native" and the like). There is such as configure.args setting ("--with-as=${prefix}/bin/as", as seen in https://trac.macports.org/browser/trunk/dports/lang/gcc48/Portfile ), which could be replaced.
Just use
as --version
AVX appeared around version 2.18.50 in gas/binutils.
It appears that I fixed my issue by using the gcc / asm syntax where asm{} function is passed a string consisting of assembler statements surrounded by quotes and separated by a backslash and newline or backslash and quoted string containing another assembler statement.
https://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#s3
I'm having a lot of trouble compiling the otherwise excellent Contiki OS on my macbook pro (with mac os x 10.6). Contiki actually uses a lot of GNU-specific features and options of GCC, AR, LD, and so on. So I installed those utilities via macports, but it looks like "port install binutils" does not install GNU ld, does it ?
So, the question is, how do I get GNU ld on my mac ? Is there a simple alternative to the hard-way (i.e. the wget, configure, make, make install way) ?
As far as I can tell, GNU binutils does not support the Mach-O format. None of the documentation mentions it, and some Googling turns up some recent messages indicating that it is not supported.
Now, you mention the Contiki OS, which looks to me like an embedded operating system. Are you needing to compile to a native executable, or are you trying to cross-compile for some other environment? MacPorts does include several ports of binutils for cross compilation.
$ port info binutils
(…) Tools are prefixed with g to avoid conflicts with original tools. (…)