[CMake] Undefined reference

[Michael Hertling]

On 11/04/2011 12:50 AM, Dan Kegel wrote:
> On Thu, Nov 3, 2011 at 4:16 PM, Michael Hertling <mhertling at online.de> wrote:
>>> Static linking of glibc is not really supported; IIRC glibc's
>>> DNS and localization support use shared libraries under
>>> the hood, even when you ask for static linking
>>
>> [statically linked utilities are essential for disaster recovery and during boot]
> 
> During boot, I think it's common practice to link against klibc,
> which totally supports static linking.
> And I agree, a statically linked busybox is a wonderful thing.

AFAIK, klibc is even targeted at the Linux early user space; OTOH,
the FAQ of BusyBox states that it is not suitable for the latter.
Instead, uClibc is preferred as a replacement for glibc, but I
have tried neither the one nor the other yet.

>> So, what do you mean when saying static linking
>> against glibc is not really supported? Do you refer to particular
>> systems or special setups? Could you provide an example?
> 
> No special system or setup.  See
> http://www.akkadia.org/drepper/no_static_linking.html
> http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead
> http://sourceware.org/bugzilla/show_bug.cgi?id=631
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=1044
> glibc decided many years ago to focus only on systems that
> supported dynamic linking, and to require its use.

Now, I see what you mean with "under the hood". ;) You're absolutely
right that for non-trivial programs not written with static linking
against glibc in mind, the latter is quite impossible. Indeed, this
might be the cause of the OP's problems. Nevertheless, if you don't
refer to any of the affected symbols - most notably the NSS stuff -
or do provide drop-in replacements for them, a self-contained static
linking against glibc should still be feasible. E.g., mdadm's static
target compiles the additional file pwgr.c with an implementation of
get{pw,gr}nam(), two critical functions. However, I have not tried
static linking against glibc for some time, and at the moment, I
can't perform a rigorous test since I've no glibc-based system
at hand which I could endanger, so correct me if I'm wrong.

> Not a popular decision, but the glibc maintainer has some rather strong
> opinions.

Yes, but UD's opinions have inspired the development of related
projects, so we've a wider choice of C libraries nowadays. ;-)

@Mauricio: Could you build your project statically with a somewhat
recent gcc as the latter warns when you use critical functions, i.e.
functions that require a dl_open'ing of shared libraries by libc.a?
If this turns out to be the issue, you might try to use a different
C library like the already mentioned klibc or uClibc, but note that
exchanging binaries among *unices won't work unless the systems are
sufficiently compatible, e.g. Linux 2.4 --> 2.6 will probably fail.

Regards,

Michael