Follow the Fedora Guidelines on static linking against
a library. If you really need to use static linking,
you should know that we can not support statically linking
against the C/C++ runtime.
This includes the use of the gcc, clang, or ld option:
-static
-static-.* e.g. -static-libstdc++
to link against any part of the C/C++ runtime[1].
This also includes the use of the Go build options:
-ldflags '-extldflags=-static -linkmode=external'
to create a go application that would otherwise have been
dynamically linked but are now statically linked against
the C/C++ runtime[2].
Note that in RHEL the glibc-static package is in the optional
repository and therefore also unsupported by virtue of this
caveat.
You may be able to statically link against other runtimes
e.g. "-Wl,-static -lfoo -Wl,-Bdynamic" to link just "foo"
statically, but please review the documentation for the
specific runtime to see if it supports this use (and don't
forget the Fedora packaging guidelines).
In all honesty we want to support some limited APIs in static
linkage, but until we document this better we can't easily
commit to any given API. The set of unsupported APIs includes
but is not limited to:
Any glibc functionality which might call dlopen.
- All NSS functions e.g. getent, getpwuid_r, etc.
- All encoding conversions (gconv/iconv).
- All IDN functionality (libidn).
- All dl* functions (libdl).
- Thread cancellation.
The primary reason for our inability to support static
linking is the same reason we have problems implementing
dlmopen (from Solaris) correctly. Namely that the static and
shared parts (those loaded by dlopen) are two distinct
namespaces and we have yet to design infrastructure to
share the process-global state that both namespaces need
in order to coordinate properly. The v2 C/C++ packaging
guidelines has more help and guidance for developers who
really need help making static linking with the C/C++
runtime safe.
In Fedora and CentOS there is no optional repository
distinction, and in these distributions we are working
on a long-term solution to this problem. A short term
solution is likely a documentation of the APIs which can
be used in a static link.
There are a few cases of core distribution binaries like
sln and ldconfig which must be statically linked. In those
cases we use our best judgement and experience to prevent
those binaries from deviating into unsupported APIs as
described above.
Lastly, keep in mind that this problem is not unique to
the C/C++ runtimes. The same problem is faced by all
libraries that may be statically linked and dlopen'd.
Such libraries face the the fact that they have been
loaded twice into the same process (or N times with
dlmopen load isolation) and must either operate
correctly or provide their own APIs for process-global
state coordination.
I am updating the C/C++ packaging guidelines to in [3]
with a new section on static linking. Once the section has
had enough review it will be put forward for FPC to vote and
update the official C/C++ packaging guidlines in [4].
Cheers,
Carlos.
[1] For the pedants in the crowd this does not include the
implementation dependent archives which may or may not be
statically linked into each object e.g. libc_nonshared.a,
libpthread_nonshared.a etc, these are
implementation-dependent details.
[2] The complexity of this caveat is because if the application
would otherwise have been statically linked it means the
go compiler determined there were no external API uses
and defaulted to linking in the required Go runtime
statically (which is a supported use case, and is not a
static linkage against the C/C++ runtime).
[3] https://fedoraproject.org/wiki/C_and_C%2B%2B_v2#Static_Linking
[4] https://fedoraproject.org/wiki/Packaging:C_and_C%2B%2B
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
