I am trying to build a project on Mac OS X using clang and it fails on linking step with ld: unknown option: --no-undefined, which is meant to built with gcc.
What's the clang equivalent for this option? (Please, don't advise to use gcc instead of clang.)
Also, a more generic question, is there any resource where one can find some kind of a "mapping" between gcc and clang (linker) options differences?
Thank you.
OS X uses a different linker. As #rubenvb points out, it's probably the one from Apple's binutils. If you run man ld, and search for "undefined", you will find this option:
-undefined treatment
Specifies how undefined symbols are to be treated. Options are: error, warning, suppress, or dynamic_lookup. The default is error.
So, replace -Wl,--no-undefined with -Wl,-undefined,error. Also, use the Force, Luke.
Related
I am trying to configure the last version of clang (6.0) to use the arm-none-eabi linker instead of the ld.lld but clang is always ignoring everything and keep asking for the ld.lld one. I am trying to build for cortex-m3 (lpx1769 board). How do I force clang to use the linker I want.
-fuse-ld=ld is also not working, so does clang no longer allow the use of any other linker?
So the answer was to use the flag:
-fuse-ld=path/to/linker-to-be-used
Remember that if you passing this flag to clang it will cause a warning that clang will not use this flag (only the linker stage will do). Thus if you compiling with -Werror, the warning will be turned into an error.
Moreover, because you are cross-compiling probably you will need to let the linker know where to find the target-specific libraries needed using the -L option. See this for more info:
https://clang.llvm.org/docs/CrossCompilation.html
I'm trying to port to Macintosh OSX where clang is provided instead of gcc. When building on Linux with gcc, I pass -static-libgcc to gcc.
What is the nearest equivalent I might replace this option when using clang?
Probably this has already been sorted out, but for the sake of completeness,
-- you cannot not link with system libraries statically on mac, till you do some extra work of compiling crt0.o.
So, simply remove this flag.
Please see
stackoverflow.com/questions/5259249/creating-static-mac-os-x-c-build
https://developer.apple.com/library/mac/qa/qa1118/_index.html
Suppose I have a third party library called somelib.a on a Mac running Mountain Lion with Xcode 4.4 installed. I want to get a dynamic library out of it called somelib.dylib. An appropriate Linux command would be:
g++ -fpic -shared -Wl,-whole-archive somelib.a -Wl,-no-whole-archive -o somelib.so
where -whole-archive and -no-whole-archive are passed to the linker.
When I do the equivalent for Mac:
g++ -fpic -shared -Wl,-whole-archive somelib.a -Wl,-no-whole-archive -o somelib.dylib
ld fails with an error:
ld: unknown option: -whole-archive
It seems that the ld on OSX is different from GNU ld. How do I have to modify above command so I will get the desired result?
Thank you in advance!
I found out the solution to my problem:
g++ -fpic -shared -Wl,-force_load somelib.a -o somelib.dylib
The required argument is -force_load:
Which needs to be followed by a single library you wanna ensure gets loaded.
I mean, it needs to be repeated for each library (unlike -noall_load approach, which wrapped them).
For example, -Wl,-force_load libYetAnotherFile.a (where -Wl, part is only required because we don't pass parameter directly to linker).
Note that Old answer (before edit) was using -noall_load instead, but nowadays that causes a linker error (as -noall_load has been removed, was obsolete previously).
Note: A link for the documentation of the OSX ld linker.
http://www.unix.com/man-page/osx/1/ld/
I know it is late to give an answer for this, but I do not have enough reputation to make a comment on #hanslovsky answer.
However, it helps me a lot to have the docs of the options too.
It helps what the options do exactly, and that other options the ld linker also has.
So I just wanted to share with others who finds linking an issue.
UPDATE:
After the comment from #GhostCat I have decided to expand my answer.
The docs for -all_load is:
-all_load
Loads all members of static archive libraries.
So it loads for all static libraries that you note.
If you want something similar to --whole-archive and --no-whole-archive, then you need to use -force_load and -noall_load.
-force_load "path_to_archive"
Loads all members of the specified static archive library. Note: -
all_load forces all members of all archives to be loaded.
This option allows you to target a specific archive.
-noall_load
This is the default. This option is obsolete.
Then you can define which libraries to fully load with -force_load and then later turn it off again with -noall_load.
According to the ld manual, -noall_load is the default and is ignored. (If you use it, you get an error message: ld: warning: option -noall_load is obsolete and being ignored)
Apparently the way to get -all_load to apply to only one library is as follows:
-Wl,-force_load,somelib.a
Where can I find a list of all available warning and error flags I can set in clang and gcc? I've looked all over both of their respective documentation sites, and I can't find anything.
gcc --help=warnings,seperate
gcc --help=warnings,joined
gcc --help=warnings,undocumented
gcc --help=warnings
seperate flags are like boolean values; they are either on or off.
-Wflag means on. -Wno-flag means off.
joined flags are flags that require a value.
-Wflag=value
by typing gcc --help=warnings you will recieve all the warning options provided by your compiler.
EDIT:
looking at GNU Documentation, these warnings messages have existed since GCC 4.3.6
GCC: http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary.
For Clang, there is -Weverything, which enables all warning flags.
The classic: man gcc. clang's manpage is not that populated yet, but since it mimics gcc's behavior anyway, many of gcc's -W options also work with clang.
If the question is just to find the list of all possible GCC diagnostic (error, warning, ...) messages, you could use the catalog of messages for localization utilities. With the GCC source tar ball, look inside gcc/po/ or libcpp/po/ or libstdc++-v3/po/ etc.
If you just ask about the options used to get these messages, follow the link in the answer by Oli Charlesworth
With GCC, when the -Wall -Wextra flags are enabled, one has the option of disabling warnings such as the following with -Wno-ignored-qualifiers:
warning: 'const' type qualifier on return type has no effect
Is there any way to achieve the same behavior with LLVM/Clang? I Googled it, but only found some patch related pages about how this error reporting feature got added. Nothing on how to disable it.
I am using LLVM & Clang version 3.0 (build from SVN sources).
Note: I was going to post this on SuperUser, but there's not a single question about Clang there and no LLVM tag either, so that kind of discouraged me. If this question should be there anyway, feel free to move it.
[Edit] It seems the option is recognized when I run my Makefile from the terminal. When ran from Eclipse (Helios), it doesn't get recognized however.
[Solution] Found it. Apparently, the problem was Eclipse (under Ubuntu) is started by root. Why this is, I have no idea, but the effect is that the $PATH variable contains what root would have, instead what the user starting Eclipse would have. As such, Eclipse was using an older system-wide installed version of Clang (2.80). Adding the correct PATH variable in Project Properties -> C/C++ Build -> Environment fixed this.
What version of Clang are you using? -Wno-ignored-qualifiers works for me:
% clang -Wall -Wextra -c foo.c
foo.c:1:1: warning: 'const' type qualifier on return type has no effect
[-Wignored-qualifiers]
const int foo();
^~~~~
1 warning generated.
% clang -Wall -Wextra -Wno-ignored-qualifiers -c foo.c
%
In general you can look at the .td files, which do a pretty nice job of collecting all the diagnostics. (There's a TODO in the Clang docs to autogenerate documentation with tblgen, but this hasn't been done yet.)
In this case for example you see in DiagnosticSemaKinds.td:
def warn_qual_return_type : Warning<
"'%0' type qualifier%s1 on return type %plural{1:has|:have}1 no effect">,
InGroup<IgnoredQualifiers>, DefaultIgnore;
which shows you what diagnostic group it's in (IgnoredQualifiers). Then you can look in DiagnosticGroups.td to see what IgnoredQualifiers is called on the command line:
def IgnoredQualifiers : DiagGroup<"ignored-qualifiers">;
So -Wno-ignored-qualifiers is it. Clang tries to be GCC-compatible wherever possible, so using the GCC name for something is usually likely to work.