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.
Related
I'm working on compiling a library in windows with GCC and Make.
When I run make, I get the following error:
unrecognized command line option '-mno-cygwin'
I saw this post on SO, but it doesn't necessarily seem like the same issue, and I don't understand how to downgrade my system to a version of GCC (or Make) that supports the flag I need to use in order to compile.
Could someone please try to point me in the right direction, or if you've run into this problem offer a solution?
I'm running Windows 8.1 pro, GCC 5.4.0, make 4.2.1.
I can post more info if it is necessary to help me.
The current cygwin gcc compiles only for cygwin itself.
-mno-cygwin is an obsolete flag from gcc 3.x time that allowed the cygwin compiler to compile mingw (not cygwin) programs.
The switch was removed long time ago and true cross compilers
mingw64-x86_64-gcc-core
mingw64-i686-gcc-core
cygwin-mingw
were made available
Latest update:
https://sourceware.org/ml/cygwin-announce/2016-11/msg00020.html
Is there an option to GCC that changes the path of the assembler it uses? I'm getting errors from Solaris /usr/ccs/bin/as when using GCC to attempt to compile Haskell, but I've got a copy of GNU as in my path so when I type which as and as --version they use the GNU version, not the Solaris version. Unfortunately it seems GCC ignores the GNU version in the path and goes to the Solaris version. I'm trying to build Haskell on Solaris and I don't think it sits well with the Solaris assembler. I hope I can change this behaviour with a simple wrapper script so I don't have to recompile GCC.
Specifying the assembler to be used is not possible at run time. It has to be done when configuring gcc:
--with-gnu-as
Specify that the compiler should assume that the assembler it finds is the GNU
assembler. However, this does not modify the rules to find an assembler and will
result in confusion if the assembler found is not actually the GNU assembler.
(Confusion may also result if the compiler finds the GNU assembler but has not
been configured with --with-gnu-as.)
Note the part I've put in italics. Of course you could temporarily change /usr/ccs/bin/as to call the gnu assembler (provided you have the necessary permissions), but the above seems to suggest that you'll very likely run into problems. The gcc build process actually checks the features the assembler supports and generates code for exactly that assembler.
I suggest you build a new version of gcc first (configured to use the gnu tools), and then use that to build ghc.
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 have build a g++ v4.4 from source by using the archives provided by gcc.gnu.org.
But the resulting g++ cannot compile some of our projects c++ files. I am receiving a message simply saying: assembler error. It turned out that the assembler chokes on some extremely long symbol names, e.g. symbols names with a length of more then 2k.
Am I missing something to get it to work?
I would very appreciate an advice on how to get this working!
Environment: Debian-Lenny 64bit
EDIT: The mentioned c++ files are compiling fine with g++ versions v4.2 and v4.3. So I don't think it is a bug in the assembler (from binutils v2.18). Just to be sure I have also tried with binutils v2.20 - but I got the identical error message.
EDIT: I need g++ v4.4.x for the purpose of comparing the output of different g++ versions (and there is no g++ v4.4 in the official lenny repositories)
If your analysis is correct, it seems the proper course of action would be to file a bug for binutils. Or gcc, if it turns out the long symbol names are due to a bug in gcc's name mangling.
Of course, a (preferably reduced) testcase will help the developers fix your problem. Heck, it could have helped SO readers to verify your problems.
You're going to have to compile the corresponding gas instead of depending on what lenny has in his refrigerator (/usr/bin).
Why don't a) upgrade or b) use the backports archive or c) rebuild from current Debian sources on your box? I happily run testing with g++ 4.2, 4.3 and 4.4.
Worst case, you could install a new Debian release in a virtual environment such as a chroot, a Xen or Kvm instance, or inside VirtualBox.
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.