in this thread
https://unix.stackexchange.com/questions/149359/what-is-the-correct-syntax-to-add-cflags-and-ldflags-to-configure
someone says that CFLAGS and LDFLAGS do not work with every configure script. Why? I would like to have more explanation about this, not just the statement ;) Under which circumstances does that work and under which doesn't it? What are the causes?
He (the accepted answer) also mentions that you should use CPATH and LIBRARY_PATH instead.
What is the difference between CFLAGS and CPATH?
Similarly what is the difference between LDFLAGS and LIBRARY_PATH?
Last question: When I use LDFLAGS = whatever, don't I override previous LDFLAGS definitions that might have been made by the developer himself? Shouldn't the syntax rather be something like ./configure LDFLAGS+=/myPath ?
CFLAGS/LDFLAGS used by ./configure, CPATH/LIBRARY_PATH used by GCC/MinGW compiler/linker. If ./configure is written good, it firstly get CFLAGS/LDFLAGS from environment before appending any paths to it and calling compiler/linker. In that case, you can use
CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" ./configure
Modern ./configures can accept CFLAGS/LDFLAGS as parameters
./configure CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib"
but if ./configure is poor or old, only CPATH/LIBRARY_PATH can help
CPATH=/usr/local/include LIBRARY_PATH=/usr/local/lib ./configure
CPATH=/usr/local/include LIBRARY_PATH=/usr/local/lib make
Altenatives to CPATH/LIBRARY_PATH for Microsoft Visual C++ Compiler is INCLUDE/LIB.
Related
I have a cc_toolchain configuration for a proprietary c compiler and I have ensured that the compilation commands are correct from the bazel output using the '-s' flag.
However, bazel adds the three compilation flags '-MD -MF and -frandom-seed' in addition to what I have specified.
My compiler does not recognize the -MD and -MF flags. No issues with the -frandom-seed.
How can I specify bazel NOT to add these flags?
To not add random seed, disable the corresponding feature, add:
random_seed_feature = feature(
name = "random_seed",
enabled = False,
)
and add random_seed_feature to list of features you pass to cc_common.create_cc_toolchain_config_info().
For -MD -MF it gets more complicated. You could disable dependency_file feature in a similar manner, but the hdrs_check would fail expecting to find a dependency dump and I do not believe you can actually disable that for C++ action with cc_toolchain based on current implementation (or no readily available method comes to mind).
The question is, does your compiler still support dumping dependencies, just using different flag(s)? Then you can (even should) redefine the feature, for reference in https://github.com/bazelbuild/rules_cc it currently for U*X-like systems looks like this:
dependency_file_feature = feature(
name = "dependency_file",
enabled = True,
flag_sets = [
flag_set(
actions = [
ACTION_NAMES.assemble,
ACTION_NAMES.preprocess_assemble,
ACTION_NAMES.c_compile,
ACTION_NAMES.cpp_compile,
ACTION_NAMES.cpp_module_compile,
ACTION_NAMES.objc_compile,
ACTION_NAMES.objcpp_compile,
ACTION_NAMES.cpp_header_parsing,
ACTION_NAMES.clif_match,
],
flag_groups = [
flag_group(
flags = ["-MD", "-MF", "%{dependency_file}"],
expand_if_available = "dependency_file",
),
],
),
],
)
If your compiler does not produce this file at all, I am afraid on top of disabling the feature you'd need to wrap its call and dump an empty file to where dependency_file is expected (essentially use a flag the wrapper understands, gets the file name and strips both from compiler call, writing an empty file for the check). You'd lose the headers checking for dependencies being correctly declared by by-passing it, but it would allow the build to proceed.
Alternatively, from scratch new cc_toolchain with own actions which does not incorporate the header checking could be an option.
I'm aware of similar questions here and here, however, the LLVM codebase changes so quickly I'm here to ask if the state of things have changed since then.
So, currently I'm trying to write an out-of-tree pass that works on the whole program CFG (hence the need for the merged bitcode). I would prefer to use the legacy PassManager as opposed to the Mixin-based NPM due to some other legacy passes my current pass relies on.
clang is called with these args:
clang -flto -Xclang -O0 -Xclang -load -Xclang ./mvxaa.so -fuse-ld=gold -o ./tests/target_app $(TARGET_SOURCES)
Will this register the pass as an LTO (full) pass? The pass never runs.
static void registerGlobalCollectionPass(const PassManagerBuilder &PB,
legacy::PassManagerBase &PM) {
PM.add(new CollectGlobals());
}
static RegisterStandardPasses
RegisterMyPass(PassManagerBuilder::EP_FullLinkTimeOptimizationEarly,
registerGlobalCollectionPass);
Looking deeper, it seems that PassManagerBuilder::addExtensionsToPM is called by the individual populateXPassManager functions and they will look through the GlobalExtensions list to call the respective callback functions. For other non-LTO ExtensionPointTy like EP_EnabledOnOptLevel0 there are entries, but when populateLTOPassManager is called, there are no longer any entries in the GlobalExtensions smallvector. Why is this the case?
Is it because LTO occurs at a later point after the linker runs and the -load argument given to dlopen the shared libraries only loads the shared objects at the compilation phase?
I am using a custom build command to run the nasm assembler on a .asm file in my C++ project. I am using %idefs in the assembler code to only compile the code I need. I am checking for the same #defines as in the C++-Code and use define() in Premake 5 to set those, but additionally I need to pass them to nasm on its command line invocation in my Custom Build Command. What I am looking for is a way to concatenate or string replace the Premake internal list of #defines into the command line invocation string of the buildcommands() call. Is there a Premake Token or a way to introspect the lua variables and generate a list from that?
Note that my command line invocation specifically is
buildcommands "nasm.exe -f win32 -o %{cfg.objdir}%{file.basename}.lib %{file.abspath} -DNDEBUG"
Suppose I set defines { "FEAT_A", "FEAT_B" } in my premake5.lua. I then would like to to add -DFEAT_A -DFEAT_B automatically to that build command similar to the -DNDEBUG so I cannot simply insert a simple token. I guess I do have to do something like this (lua pseudo code as I don't really know the syntax):
define_flags = wks.defines.join(" -D")
buildcoommands("nasm.exe [...]"..define_flags)
Do you know if something like this is possible?
How about something like this?
buildcommands('nasm.exe [...] %{table.implode(cfg.defines, "-D", "", " ")} [...]')
I am using Android-sdk-ndk in an Eclipse+ADT environment. In Android-sdk Java development, I could use "Log.i", "Log.w", ... statements to output messages and variable contents to the "LogCat" window. However, in Android-ndk C/C++ development, is there any similar C/C++ "print-like" statement that outputs messages / variable contents from a JNI C/C++ module to the "LogCat" window so that I could have some debug informations for my program.
Thanks for any suggestion.
Lawrence
From this guide: http://www.srombauts.fr/2011/03/06/standalone-toolchain/
You can #define the logging methods like this:
#define LOGI(...) ((void)__android_log_print(ANDROID_LOG_INFO, "hello-ndk", __VA_ARGS__))
And you need to make sure you're linking to liblog by compiling similar to this (just add -l log):
arm-linux-androideabi-gcc hello-ndk.c -l log -o hello-ndk
Where can I find a complete list of Clang flags?
There are some, like -include-pch, that don't appear to be even listed in the man page. :(
I know that GCC uses some of the same flags, but it doesn't include documentation for stuff like -Os which I believe is only available in Clang. Is there a place where I can find a single, consolidated list of all the Clang options ever?
I don't know if this is exactly what you want. Maybe more options are described elsewhere, but I think you are interested in the Clang frontend options. By default, the options displayed seem to describe the "GCC-compatible driver".
clang -cc1 --help should give you what you want.
For Clang, they are listed in the diagnostics reference, which can be found on the documentation website here
There are many hidden options in LLVM:
clang --help-hidden
opt --help-hidden
If you want to get a complete list of warning flags, including hierarchies (IE which sub-flags are enabled by groups like -Wall), you can use the LLVM tool diagtool.
$ diagtool tree Will print the complete list of warnings clang supports.
$ diagtool tree -Wnon-gcc will print the warnings enabled by -Wnon-gcc.
The warnings are color-coded:
RED = it does nothing, exists only for GCC compatibility
GREEN = the warning is enabled by default
YELLOW = the flag enables new behavior
Finally, I wrote a short script if you're interested in viewing the diff between sets of flags (see image below)
For example: -Wall -> -Wall -Wextra ->-Wall -Wextra -Wnon-gcc:
https://twitter.com/GavinRayDev/status/1599126252136280064
https://gist.github.com/GavinRay97/c28ca31a86f6a106bb46e426e2603be0
Here is a set of flags not enabled by your typical -Wall -Wextra -Wpedantic for Clang (as of LLVM 16 dev) you might find useful, that I scraped from the output of diagtool:
https://gist.github.com/GavinRay97/bae1d93925e55ce0a0084946f24984cf
Hope someone out there finds this information useful =)