I am using GCC ver-4.6.4 (both in Mac and Linux Mint 15) to compile a code I do for research.
The command I am using is :
gfortran -O2 -fopenmp -Wl,-stack_size,1000000 <...Lots of files...> -o a.out
, where I omit the actual file names.
This code compiles OK in Mac, however I get the following error in Mint:
/usr/bin/ld: unrecognized -a option `ck_size'
collect2: error: ld returned 1 exit status
make[1]: *** [a.out] Error 1
In Mint, this will compile if I do not use any flags at all, therefore this problem is related to OpenMP.
However, I do need OpenMP and do not understand what it says in the error, because I do not have 'ck_size'. BTW, deleting -O2 doesn't help.
The problem is not related to OpenMP, it is related to your different OS's.
-stack_size is specific to Macintosh and refers to the maximal size of arrays on the stack. Linux changes the stack size via the terminal command ulimit (to check your Mint settings type, ulimit -a to see everything, the stack size can be seen with ulimit -s, see the ulimit man page for more information).
Thus, you need to scrap that whole -stack_size,100000 portion from your compiler flag, it means nothing in Linux.
You passed -Wl,-stack_size,1000000 to gfortran, which is passing on the option "-stack_size 1000000" to the linker ld. It is interpreting "st" as single letter options "-s" and "-t", then reading the next letter as an option "-a", and the rest of the word ("ck_size") as its parameter.
I could find no reference to a -stack_size option for ld. It looks like the option is --stack, so you need to put something like -Wl,--stack,1000000 instead.
Related
I am trying to build a dll in C++ in which I use a C dll with prototypes like :
int __stdcall foo();.
When linking, the compiler outputs:
Warning: resolving _foo#0 by linking to _foo
Use --enable-stdcall-fixup to disable these warnings
so I added the option when linking, the command looks like:
g++ -std=c++0x -o fooLib.dll fooObj.o -lfooClib --enable-stdcall-fixup -shared
but seems like the g++ doesn't know this option:
g++.exe: error: unrecognized option '--enable-stdcall-fixup'
when I am adding only -enable-stdcall-fixup (one hyphen), it still shows the warnings (looks like has the option has no effect), and the ouput is kind weird:
g++ -std=c++0x -o fooLib.dll fooObj.o -lfooClib -enable-stdcall-fixup -shared
Warning: resolving _foo#0 by linking to _foo
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
ld.exe: warning: cannot find entry symbol nable-stdcall-fixup; defaulting to 679c1000
so does any body know what I am doing wrong ?
g++ --version
g++ (GCC) 4.6.1
Indeed, --enable-stdcall-fixup is not a g++ option. It's a linker option, and you can find it in the ld(1) manpage:
--enable-stdcall-fixup
--disable-stdcall-fixup
If the link finds a symbol that it cannot resolve, it will attempt
to do "fuzzy linking" by looking for another defined symbol that
differs only in the format of the symbol name (cdecl vs stdcall)
and will resolve that symbol by linking to the match. For example,
the undefined symbol "_foo" might be linked to the function
"_foo#12", or the undefined symbol "_bar#16" might be linked to the
function "_bar". When the linker does this, it prints a warning,
since it normally should have failed to link, but sometimes import
libraries generated from third-party dlls may need this feature to
be usable. If you specify --enable-stdcall-fixup, this feature is
fully enabled and warnings are not printed. If you specify
--disable-stdcall-fixup, this feature is disabled and such
mismatches are considered to be errors. [This option is specific
to the i386 PE targeted port of the linker]
gcc is able to recognize some common linker options and pass them on to ld. For example, gcc passes the -llibrary options used to link in library code directly to the linker, as well as an option -e which will be relevant below. Whenever this is the case, it's documented in the gcc(1) manpage.
As you've discovered, this is not the case with --enable-stdcall-fixup, so you'll need to explicitly pass it. In order to pass arbitrary options to the linker, gcc has -Wl. From gcc(1):
-Wl,option
Pass option as an option to the linker. [...]
So in your case, you would call
g++ -Wl,--enable-stdcall-fixup [...]
I don't have the version of the linker mentioned in the manpage, so it still comes up as an unrecognized option for me. But on your system, given that the linker is telling you to use the option, I can only assume it is the version that recognizes it.
As an aside, when you tried calling the option with only one dash, you ran into a red herring. You were actually invoking the -e gcc option that I mentioned above, with the option argument nable-stdcall-fixup. From gcc(1):
-e entry
--entry=entry
Specify that the program entry point is entry. The argument is
interpreted by the linker; the GNU linker accepts either a symbol
name or an address.
So you actually ended up passing an option to the linker saying that, when you execute your program, you want it to begin execution from a function named nable-stdcall-fixup instead of the usual main.
I am using arm-none-eabi-gcc for STM32
I am trying to generate cross-reference table by passing option '--cref' to the linker, but I get this error
arm-none-eabi-gcc: error: unrecognized command line option '--cref'; did you mean '--xref'?
is '--xref' a replacement for '--cref' ?
--cref is an option for the GNU binutils linker, ld, but it is not an option of gcc
You can direct gcc to pass such options through to ld when it invokes the linker by using the the
gcc option -Wl, which has the usage:
-Wl,<ld-option>[,<ld-option>...]
So, instead of --cref, pass -Wl,--cref in your gcc commandline.
By itself, this will make the linker print the cross-reference table on the standard output. If you
would prefer to have it in a mapfile, then request a mapfile from the linker as well and the cross-reference
table will be appended to it: -Wl,--cref,-Map=mapfile
(--xref was an option for gcc long ago. It is not longer one, but the commandline
parser will still suggest it as one that you might have meant when it parses an unknown
option.)
Simple question. I am compiling an ada program with gnat. The gcc command ends up looking like gcc -c -Ia -Ibunch -Iof -Iincludes -I- -o /some/object/file.o /some/source/file.adb however the error format consists of just file.adb:line:offset: problem.
Is there any way to get GNAT make or gcc to print the full path to the file in its errors, as specified on the command line? IE: to get /some/source/file.adb:line:offset: problem.
I know that with the -gnatv one could argue that it prints the full path, but I want something significantly less verbose than that.
you need -gnatef option:
-gnatef
Display full source path name in brief error messages.
gcc -gnatef -c %CD%\file.adb
C:\DATA\jff\data\python\stackoverflow\file.adb:1:01: "procedure" expected
https://gcc.gnu.org/onlinedocs/gcc-4.3.6/gnat_ugn_unw/Switches-for-gcc.html
I want to use gold as my system linker instead of ld as ld doesn't support -fPIC and -shared.
I followed this particular url to do so,
gold-plugin
As per the documentation,
I ran gcc -v filename.c to find out what link command gcc would run.
Then it tells me to check for line that runs collect2 and replace it with -plugin /path/to/LLVMgold.so. But gcc and collect2 are binary files.
I studied a bit..and understood gcc calls collect2 ,in turn collect2 calls system linker ld by searching for ld-linux.so.2.
I have rpm packeage of gcc4.4.4 installed on my fedora...how can I change my configuration.
How can I make gcc call ld-new/gold instead of collect2?
I'm a bit late to answer, but I realised Fedora comes out with gold distributed with binutils. The command is ld.gold. You can select it as the default linker using alternatives :
# alternatives --config ld
There is 2 program that provides 'ld'.
Selection Command
-----------------------------------------------
*+ 1 /usr/bin/ld.bfd
2 /usr/bin/ld.gold
Enter to keep the current selection[+], or type selection number: 2
As I read standard tools like ld or ar can't be renamed or have extension like ld_1.6 or whatever. maybe you can change name of ld_new to ld and put its address before PATH in .login.user file or add temporally in command line. Then when ever any program calls ld you can be sure your ld will be invoked first, its the way that I am using ld-gold without changing bin/ld.
In short, I have the most recent version of MinGW and I am attempting to pass options into the linker and the like.
For example, I wanted to change the stack size by:
gcc -Wl,--stack,[new size in bytes]
But it recognized neither -Wl nor --stack. And that applies for the other options too.
I'm able to compile my programs all well in good, it just seems as though I cannot use the various gcc options.
Is this an issue with MinGW, or am I overlooking something more?
I just confirmed in the documentation about passing arguments to linker, that you cannot have a space before the number, so it should be:
gcc -Wl,--stack,[new size in bytes]
Commas are changed into spaces, but a real space makes the next option gcc option, not linker option.