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.
Related
I wanted to upgrade to binutils 2.26 , so i followed the steps here : How to convert default binutils into binutils-2.26? to solve the same "unrecognized relocation" error.
Now my default linker is 2.26
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.26.1
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
But "make" still uses the "/usr/bin/x86_64-linux-gnu-ld" (which is 2.24) and still gives the same error.
So how to force "make" to use the default linker ?
It depends upon your Makefile (which you could debug with remake -x). Notice that make has a lot of builtin rules. Use make -p to also print them. Notice the rules mentioning LINK.c or LINK.cc etc, and notice that LD is not much used. Notice also that ld is almost never used directly (most of the time, some other program like gcc or g++ runs it).
And it is also a matter of the PATH variable. So try setting it so that your new ld comes before the old one.
Generally, you link with the gcc or g++ program (so it is GCC which matters, not make; read about Invoking GCC and its -fuse-ld=), and that gcc or g++ will run the linker (you might, but I don't recommend to, change its spec file which governs what actual programs are run by gcc or g++ which are only drivers to other programs such as cc1, as, ld, collect2 etc...). To understand what programs gcc or g++ is running, pass it the -v flag.
But "make" still uses the "/usr/bin/x86_64-linux-gnu-ld" (which is 2.24) and still gives the same error.
On my Debian system /usr/bin/x86_64-linux-gnu-ld (it is generally started by gcc, not directly by make) is a symlink. You might (but I don't recommend that) just change that symlink.
BTW, you are using an ancient Ubuntu 14. You'll better upgrade your entire distribution (e.g. to Ubuntu 18.04.1 LTS at end of 2018), because there is not only ld but many other programs which are really old on your system.
Upgrading your distribution will take less time than upgrading, compiling, installing and configuring each individual tool.
I have been tweaking GCC 6.3.0 to get it to use the libc++ runtime instead of libstdc++ so that g++ can be used without worrying about C++ runtime incompatibilities:
https://github.com/RJVB/macstrop/tree/master/lang/gcc6
The tweak works, I can build and run KDE software using g++ against Qt5 and KF5 frameworks (and everything else) built with various clang versions.
What doesn't work is generating code that uses AVX and presumably most or all newer intrinsic instructions.
This is not a new issue that's never been invoked on here; it's answered here for instance: How to use AVX/pclmulqdq on Mac OS X
Evidently one can configure gcc to call the linked script instead of the actual as executable.
But can gcc not be configured to use another assembler altogether, like nasm, and would that solve this issue?
I am new to porting gcc, just want to ask, if I only want gcc to generate assembly language for each files can I skip porting Binutils ?
Sure. Are you trying to port gcc as cross-compiler? You should configure with --disable-bootstrap and use make all-gcc when building it (i.e. skip libgcc, glibc, libstdc++ build). Then you will get pure compiler to work from source to target assembler only.
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 am new to llvm/clang and have successfully built clang with MinGW.
I have one simple question - is MinGW gcc still needed for clang to work as a c/c++ compiler?
Thanks,
jweiboman
Right now - unfortunately, yes. clang will use gcc to assemble / link the stuff. This is necessary to e.g. provide the proper cmdline for linker invocation adding CRT objects & libraries.
As soon as someone will provide the the complete "toolchain" definition for mingw in clang, this won't be necessary. Only assembler and linker (part of binutils) will be required.