QA Notices
Here we'll go over each QA notice and what you (as a developer) can do to fix
the issue. If you're a user, you should of course go
file a bug. We'll only cover the
non-obvious notices here.
In pretty much all cases, you should try and get these issues resolved
upstream rather than simply fixing them in our ebuilds.
Scanelf: Insecure RUNPATHs
QA Notice: The following files contain insecure RUNPATH's
Some of the ELFs that would be installed on the system have insecure dynamic
RUNPATH tags. RUNPATH tags are a hardcoded list of filesystem paths that
will be searched at runtime when the ELF is executed. If the ELF has a
world accessible directory hardcoded in it, then a malicious person can
inject code at runtime by adding their own libraries to the directory.
Here are some of the common problems and their solutions.
Libtool - old versions of libtool would use too many -rpath flagsSolution: Regenerate the autotool codePerl - some versions of perl would use incorrect -rpath flagsSolution: upgrade system perl build modulesCrappy build system - the custom build system uses -rpath incorrectlySolution: review the LDFLAGS in the build system and make them not suckCrappy ebuild - the ebuild installs ELFs instead of using the package's build systemSolution: fix the crappy ebuild to use the package's build systemScanelf: Runtime Text Relocations (TEXTRELS)
QA Notice: The following files contain runtime text relocations
Please see the Gentoo Hardened PIC Fix Guide.
Scanelf: Executable Stack (EXECSTACK)
QA Notice: The following files contain executable stacks
Please see the Gentoo Hardened GNU Stack Guide.
Scanelf: Missing Shared Object Name (SONAME)
QA Notice: The following shared libraries lack a SONAME
A shared library that you would link against lacks an ELF SONAME tag. With
simpler libraries, this can be acceptable, but with any sort of ABI sane
setup, you need the SONAME tag. This tag is how the system linker tells the
loader what libraries a program needs at runtime. With a missing SONAME,
the linker needs to guess and with many cases, this guess will not work for
long.
To fix this issue, make sure the shared library is linked with the proper
flag. You will need to replace the
... part with the actual ABI name. For example,
if the library is named libfoo.so.1.2.3, you will
probably want to specify .
Note that this warning only applies to shared libraries that you would link
against. It certainly does not apply to plugins that you would dynamically
load. However, plugins should not exist in the main library directory, but
rather an application specific subdirectory in the library directory. In
other words, it should be /usr/lib/app/plugin.so rather
than /usr/lib/plugin.so.
Scanelf: Missing Needed Entries
QA Notice: The following shared libraries lack NEEDED entries
This warning comes up when a library does not actually seem to need any
other libraries in order to run. Rarely is this true as almost every
library will need at least the system C library.
Once you've determined that the library is indeed being generated
incorrectly, you will need to dig into the build system to make sure that
it pulls in the libraries it needs. Often times, this is because the
build system invokes the system linker (ld) directly
instead of the system compiler driver (gcc).
Absolute Symlink In Library Directory
QA Notice: Found an absolute symlink in a library directory
If you want to use symlinks in library directories, please use either a
relative symlink or a linker script. This can cause problems when working
with cross-compiler systems or when accessing systems in a different ROOT
directory.
If you have a library installed into /lib/ and you want
to have it accessible in /usr/lib/, then you should
generate a linker script so that the system toolchain can handle it properly.
Please see the linker script section
for more information.
Missing Linker Script
QA Notice: Missing gen_usr_ldscript
If you have a shared library in /lib/ and a static
library in /usr/lib/, but no linker script in
/usr/lib/, then the toolchain will choose the incorrect
version when linking. The system linker will find the static library first
and not bother searching for a dynamic version. To overcome this, you need
to use the gen_usr_ldscript function found in the
toolchain-funcs.eclass. Refer to the
man page for information on how to use it. See this
bug report for some history
on this issue.
Excessive Files in /
QA Notice: Excessive files found in the / partition
You should not store files that are not critical to boot and recovery in
the root filesystem. This means that static libraries and libtool scripts do
not belong in the /lib/ directory. Fix your ebuild so
it does not install there.
Portage Tempdir In Libtool Scripts
QA Notice: ... appears to contain PORTAGE_TMPDIR paths
Older versions of libtool would incorrectly record the build and/or install
directory in the libtool script (*.la). This would lead to problems when
building other things against your package as libtool would be confused by
the old paths.
You may be able to cheat and use the elibtoolize function
in the libtool.eclass. However, if
that does not help, you will probably need to regenerate all of the autotool
files.
Build Warning: Strict Aliasing
QA Notice: Package has poor programming practices which may compile
fine but exhibit random runtime failures.
...: warning: dereferencing type-punned pointer will break strict-aliasing rules
This warning crops up when code starts casting distinct pointer types and
then dereferencing them. Generally, this is a violation of aliasing rules
which are part of the C standard. Historically, these warnings did not show
up as the optimization was not turned on by default. With gcc-4.1.x and
newer though, the -O2 optimization level enables strict aliasing support.
For information, please review these links:
NetBSD Explanation,
Gentoo Dev Thread,
GCC Docs
To fix this issue, use the methods proposed in the links mentioned earlier.
If you're unable to do so, then a work around would be to append the gcc
-fno-strict-aliasing flag to CFLAGS in the ebuild.
Build Warning: Implicit Declarations
QA Notice: Package has poor programming practices which may compile
fine but exhibit random runtime failures.
...: warning: implicit declaration of function ...
...: warning: incompatible implicit declaration of built-in function ...
Your code is calling functions which lack prototypes. In C++, this would
have been a build failure, but C is lazy so you just get a warning. This
can be a problem as gcc has to guess at what sort of arguments a function
takes based upon how it was called and often times, this is not the same
as what the function actually takes. The function return type is also
unknown so it's just assumed to be an integer (which is often times wrong).
This can get to be a problem when the size of the types guessed do not
actually match the size of the types the function expects. Generally, this
corresponds directly to proper coding practices (and the lack thereof).
Also, by including proper prototypes, the compiler often helps by checking
types used, proper number of arguments passed, etc...
To fix this, just include the proper header files for the functions in
question. If the function is a package-specific one, then you may have to
create a header/function prototype for it.
Build Warning: Used Uninitialized
QA Notice: Package has poor programming practices which may compile
fine but exhibit random runtime failures.
...: warning: is used uninitialized in this function
This means code uses a variable without actually setting it first. In other
words, the code is basically using random garbage.
The fix here is simple: make sure variables are initialized properly before
using them.
Build Warning: Invalid X<=Y<=Z Comparisons
QA Notice: Package has poor programming practices which may compile
fine but exhibit random runtime failures.
...: warning: comparisons like X<=Y<=Z do not have their mathematical meaning
This warning crops up either when the programmer expected the expression
to work or they just forgot to use sufficient parentheses. For example,
the following code snippets are wrong (we won't get into the technical
argument of this being valid C code; just change the code to not be
ambiguous).
if (x <= y <= z)
...;
if (a < b <= c)
...;
To fix this, read the code to figure out what exactly the programmer meant.
Build Warning: Non-Null Required
QA Notice: Package has poor programming practices which may compile
fine but exhibit random runtime failures.
...: warning: null argument where non-null required
Many functions take pointers as arguments and require that the pointer never
be NULL. To this end, you can declare function prototypes that instruct the
compiler to do simple checks to make sure people do not incorrectly call the
function with NULL values. This warning pops up when someone calls a
function and they use NULL when they should not. Depending on the library,
the function may actually crash (they told you not to use NULL after-all, so
it's your fault :P).
You will need to read the code and fix it so that it does not incorrectly
call the relevant functions with NULL values.
Build Warning: Truncating Pointers
QA Notice: Package has poor programming practices which may compile
but will almost certainly crash on 64bit architectures.
A large portion of code in the open source world is developed on the 32bit
x86 architecture. Unfortunately, this has led to many pieces of code not
handling pointer types properly. When compiled and run on a 64bit
architecture, the code in question will probably crash horribly. Some
common examples are assuming that an integer type is large enough to hold
pointers. This is true on 32bit architectures (an integer can hold 32bits
and a pointer is 32bits big), but not true on 64bit architectures (an
integer still holds just 32bits, but a pointer is 64bits big).
Since this issue can manifest itself in many ways (as there are many ways to
improperly truncate a pointer), you will need to read the source code
starting with the displayed warning. Make sure types are declared, used,
and passed properly. Make sure that all function prototypes are found (see
the Implicit Declarations
section for more information). So on and so forth.