Howto fix-FPIC errors (zz)

Content:

• The Problem
• What is pic?
• What are "relocations "?
• Case 1: Broken Compiler
• Case 2: broken'-FPIC 'support checks in configure
• Case 3: lack of '-FPIC' flag in the software to be built
• Case 4: Linking dynamically against static Archives

3..
The Problem

Sometimes it occurs that GCC bails out with an error message like
Following:

Code listing 1.1: a typical GCC error message

.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be usedwhen making a shared object; recompile with -fPIC .libs/assert.o: could notread symbols: Bad value

There are several different types of causes for such an error. This howto will
Explain all of them and show how to fix them.

3. B.
What is pic?

PIC is an abbreviation for position-independent code
. The following is
An excerpt of the Wikipedia article
About Position-independent code:

"In computing, position-independent code (PIC) or position-independent
Executable (PIE) is object code that can execute at different locations in
Memory. PIC is commonly used for shared libraries, so that the same library
Code can be mapped to a location in each application (using the virtual memory
System) where it won't overlap the application or other shared libraries. PIC
Was also used on older computer systems lacking an MMU, so that the operating
System cocould keep applications away from each other.

Position-independent code can be copied to any memory location
Modification and executed, unlike relocatable code, which requires special
Processing by a link editor or program loader to make it suitable for execution
At a given location. Code must generally be written or compiled in a special
Fashion in order to be position independent. Instructions that refer
Specific memory addresses, such as absolute branches, must be replaced
Equivalent program counter relative instructions. The extra indirection may
Cause PIC code to be less efficient, although modern processors are designed
Ameliorate this ."

-Wikipedia encyclopaedia

On certain ubuntures (amd64 amongst them), shared libraries must
Be
"Pic-enabled ".

3. C.
What are "relocations "?

Again, from Wikipedia:

"In computer science, relocation refers to the process of replacing symbolic
References or names of libraries with actual usable addresses in memory before
Running a program. It is typically done by the linker during compilation,
Although it can be done at run-time by a loader. compilers or schedulers
Typically generate the executable with zero as the lower-most, starting
Address. Before the execution of object code, these addresses shocould be
Adjusted so that they denote the correct runtime addresses ."

-Wikipedia encyclopaedia

With these terms defined, we can finally have a look at the different scenarios
Where breakage occurs:

3. d.
Case 1: Broken Compiler

At least GCC 3.4 is known to have a broken Implementation of
-Fvisibility-inlines-hidden
Flag. The use of this flag is therefore
Highly discouraged, reported bugs are usually marked as resolved invalid. See
Bug 108872
For an example of
Typical error message caused by this flag.

3. E.
Case 2: broken'-FPIC 'support checks in configure

Ingress configure
Tools check whether the compiler supports the-FPIC
Flag or not. They do so by compiling a minimalistic program with
-FPIC
Flag and checking stderr
. If the compiler prints * any *
Warnings, it is assumed that the-FPIC
Flag is not supported by
Compiler and is therefore abandoned. Unfortunately, if the user specifies
Non-existing flag (I. e. c ++-only flags in cflags
Or flags introduced
Newer versions of GCC but unknown to older ones), GCC prints a warning too,
Resulting in borkage.

To prevent this kind of breakage, The amd64 profiles use a bashrc that filters
Out invalid flags in C [XX] flags
.

See Bug 122208
For
Example.

3. f.
Case 3: lack of '-FPIC' flag in the software to be built

This is the most common case. It is a real bug in the build system and shoshould
Be fixed in the ebuild, preferably with a patch that is sent upstream.
Assuming the error message looks like this:

Code listing 6.1: A sample error message

.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be usedwhen making a shared object; recompile with -fPIC .libs/assert.o: could notread symbols: Bad value

This means that the file assert. o
Was not compiled with
-FPIC
Flag, which it shoshould. When you fix this kind of error, make sure
Only objects that are used in shared libraries are compiled with-FPIC
.

In this case, globally adding-FPIC
To C [XX] flags
Resolves
Issue, although this practice is discouraged because the executables end up
Being pic-enabled, too.

Note: Adding the-FPIC Flag to the linking command or ldflags Won't Help.

3. G.
Case 4: Linking dynamically against static Archives

Sometimes a package tries to build shared libraries using statically built
Archives which are not pic-enabled. There are two main reasons why this
Happens:

Often it is the result of Mixing use = static
And use =-static
. If
Library package can be built statically by setting use = static
, It
Usually doesn' t create a. So
File but only a.
Archive. However, when GCC is given the-l
Flag to link to said (dynamic
Or static) library, it falls back to the static archive when it can't find
Shared Lib. In this case, the preferred solution is to build the static library
Using the-FPIC
Flag too.

Warning: Only build the static archive with-FPIC On amd64. on other Ubuntures this is unneeded and will have a performance impact at Execution Time.

See bugs 88360
And MySQL bug 8796
For an example.

Sometimes it is also the case that a library isn' t intended to be a shared
Library at all, e.g. Because it makes heavy usage of global variables. In this
Case the solution is to turn the to-be-built shared library into a static one.

See bugs 131460
For an example.

Code listing 7.1: A sample error message

gcc -fPIC -DSHARED_OBJECT -c lex.yy.cgcc -shared -o html2txt.so lex.yy.o -lflusr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a(libyywrap.o):relocation R_X86_64_32 against `a local symbol' can not be used when making ashared object; recompile with -fPIC/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/libfl.a: could notread symbols: Bad value