When I build Boost (1.69) with b2 on my system (Devuan ASCII), I get several warning messages about "non-free usage":
warning: non-free usage requirements <runtime-link>shared ignored
warning: in main-target build_options at libs/locale/build/Jamfile.v2:414
warning: non-free usage requirements <runtime-link>shared ignored
warning: in main-target build_flags at libs/locale/build/Jamfile.v2:415
My questions:
What do these messages mean?
Why am I getting them?
Can I / Should I do something to avoid them?
What do these messages mean?
It means that there's a build feature that normally propagates "downwards" is being specified to propagate "upwards". In this case as a "usage-requirement". This can be a problem as it can cause your target to change how it's built from using a different library.
Why am I getting them?
They come from usage-requirements in the Boost.Locale library here. AFAICT it's a bug in the library's build file.
Can I / Should I do something to avoid them?
I think you (a) should report it as a bug to the authors and (b) ignore it for now since as far as I can tell those targets do not affect the overall build of the library itself nor of other Boost libraries.
Related
I am trying to build GridDB from source code on MacOS as recommended How to setup GridDB on macOS with instructions https://docs.griddb.net/gettingstarted/using-source-code/#build-a-server-and-client-java.
During the automake step, I get the following warning(s) for many source files:
3rd_party/MessagePack/Makefile.am:8: warning: source file '$(srcdir)/src/objectc.c' is in a subdirectory,
3rd_party/MessagePack/Makefile.am:8: but option 'subdir-objects' is disabled
Has anyone else had this? Any advice of how to make solve this warning? Is it critical in the make process?
There is a subtle difference between a warning and an error.
Both indicate problems, but while an error indicates a fatal problem that requires a solution right now, a warning is just that: a hint that there's a potential problem.
So: there's no need to solve anything right now.
As a user (of GridDB), you (normally) can ignore any such warning.
However, the maintainers (of GridDB) should look into that, as the warning might turn into an error as the world outside evolves.
Having said that, afaict not using subdir-objects with sources in subdirectories is not a problem per se, and some might prefer it that way. automake tries to push towards subdir-objects, as it fixes problems if you have multiple files with the same name in different directories. However, this (multiple same-named files in different directories) is not the case here.
Does gcc define a macro of some sort when the flag -fprofile-generate is specified? Basically, I want to disable multithreading when I'm profiling--it seems to have a way of corrupting the .gcda files.
This unanswered question is quite old, but I was having similar issues, so I hope this can be useful to someone.
You should try enabling the -fprofile-correction GCC compiler flag when using the profile information generated by a multi-threaded application. According to the GCC documentation relative to this flag:
Profiles collected using an instrumented binary for multi-threaded programs may be inconsistent due to missed counter updates. When this option is specified, GCC uses heuristics to correct or smooth out such inconsistencies. By default, GCC emits an error message when an inconsistent profile is detected.
It will get rid of the errors indicating that the .gcda files are corrupted by correcting inconsistent profile values due to multi-threading.
Here's a different one from the usual confusion over duplicate symbol errors... :-)
I'm working on some legacy Mac code in an Xcode project that has the same global, "trace", defined in several different source files - for instance:
File1.c: SInt32 trace;
File2.c: Boolean trace;
etc. It's clear the original author meant them to have file-specific scope, but just neglected to prefix any of these lines with "static". That's fine, easy enough to fix.
But I'm kind of shocked the linker isn't flagging these! It looks to me like Xcode's linker (I presume gnu ld) only emits duplicate symbol warnings or errors for functions, that are linked into the code segment - but not global variables that are linked into the data segment. Instead, it silently conflates them, which is causing bugs.
So... how do I convince Xcode to emit link errors for duplicate global variables? Or get this information in some other way that can be a routine part of my build?
Well, I thought I'd answered my own question... :-)
I posted earlier:
So if you're using Xcode with LLVM GCC
4.2, go to the build settings dialog, find the "LLVM GCC 4.2 - Code
Generation" section, and check the "No
Common Blocks" checkbox. This enables
the compiler's "-fno-common" option,
and changes the object file generation
so that ld will choke and emit an
error if you have two globals in
different source files with the same
name.
Unfortunately, that doesn't seem to solve all instances. It seems to work fine if all the globals have the same type.
But the example in the question is taken straight from the code, where a variable named "trace" is defined as a global in two different files with two different types. And that's still not caught by the build system when I check that checkbox.
I compile my Xcode projects with very high warnings settings. Sometimes, I have to use third-party frameworks that are distributed as source (rather than as a framework). These frameworks often throw a lot of warnings.
Is there a way to turn off warnings for these folders? I want the stricter level for my own code, but don't care if third-party code violates my warnings level.
Basically, I don't want to see 67 warnings every time I build.
You're looking for this:
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
Flags can be found here: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Warning-Options.html
Just replace the -W... with whatever you want to ignore.
I'm working on a project that will read compiler error messages of a particular variety and do useful things with them. The sample codebase I'm testing this on (a random open-source application), and hence rebuilding frequently, contains a few bits that generate warnings, which are of no interest to me.
How do I disable all warnings from GCC, so I can just see error messages if there are any?
-w is the GCC-wide option to disable warning messages.