Home > Archive > Unix Programming > January 2008 > Linking nsswitch apps statically?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Linking nsswitch apps statically?
|
|
| Dom Fulton 2008-01-21, 7:28 pm |
| I've got an app which I need to link statically for production use, so
that users aren't faced with interminable dependency issues. The
problem is that it uses 'gethostbyname' (and possibly other routines)
which, it seems, can't be statically linked against. On Linux, I get a
warning:
> warning: using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking.
The Linux nsswitch.conf(5) says:
> With Solaris, it isn't possible to link programs using the NSS Service statically. With Linux,
> this is no problem.
Well, excuse me, but requiring a user to have the same glibc version
that the developer used for static linking is, in my book, much the
same as saying that you can't link statically on Linux either.
Any ideas on workarounds in Linux? This app shows up bugs in various
glibc distributions, so dynamic linking isn't an option.
Is the man page correct about Solaris? I guess that I could link
dynamically on Solaris, given that anyone using the code will be on
Solaris 10.
Thanks -
Dom
| |
| Casper H.S. Dik 2008-01-21, 7:28 pm |
| Dom Fulton <wes104@yahoo.com> writes:
>Is the man page correct about Solaris? I guess that I could link
>dynamically on Solaris, given that anyone using the code will be on
>Solaris 10.
Yes, you cannot link such applications statically in any Solaris
version. It requires dynmic linekr support which isn't present for
statically linked executables.
Solaris prides itself in binary compatibiliy; linking dynamically
on the oldest version of the OS you wish to support will give
you a binary which runs on that version and all later versions.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Rich Teer 2008-01-21, 7:28 pm |
| On Mon, 21 Jan 2008, Dom Fulton wrote:
> Is the man page correct about Solaris? I guess that I could link
> dynamically on Solaris, given that anyone using the code will be on
> Solaris 10.
Statically linking with system libraries isn't possible on Solaris,
because the .a archive files don't exist. Dynamic linking is the
only way.
--
Rich Teer, SCSA, SCNA, SCSECA, OGB member
CEO,
My Online Home Inventory
URLs: http://www.rite-group.com/rich
http://www.linkedin.com/in/richteer
http://www.myonlinehomeinventory.com
| |
| fnegroni 2008-01-21, 7:28 pm |
| On Linux, apparently, there is a kludge that allows static linking to
take place, by statically linking the nss switch functionality into
glibc and then linking with that new static glibc.
Effectively you are giving up on the dynamic nsswitch but gain a
static library.
Quote from gcc.gnu.org mailing list:
2.22. Even statically linked programs need some shared libraries
which is not acceptable for me. What can I do?
{AJ} NSS (for details just type `info libc "Name Service Switch"')
won't
work properly without shared libraries. NSS allows using different
services
(e.g. NIS, files, db, hesiod) by just changing one configuration file
(/etc/nsswitch.conf) without relinking any programs. The only
di vantage
is that now static libraries need to access shared libraries. This is
handled transparently by the GNU C library.
A solution is to configure glibc with --enable-static-nss. In this
case you
can create a static binary that will use only the services dns and
files
(change /etc/nsswitch.conf for this). You need to link explicitly
against
all these services. For example:
gcc -static test-netdb.c -o test-netdb.c \
-lc -lnss_files -lnss_dns -lresolv
The problem with this approach is that you've got to link every static
program that uses NSS routines with all those libraries.
{UD} In fact, one cannot say anymore that a libc compiled with this
option is using NSS. There is no switch anymore. Therefore it is
*highly* recommended *not* to use --enable-static-nss since this makes
the behaviour of the programs on the system inconsistent.
| |
| Frank Cusack 2008-01-21, 7:28 pm |
| On Mon, 21 Jan 2008 14:19:01 +0000 Dom Fulton <wes104@yahoo.com> wrote:
> Any ideas on workarounds in Linux? This app shows up bugs in various
> glibc distributions, so dynamic linking isn't an option.
if you know where the bugs are, you could reimplement those parts of
glibc yourself to guarantee correctness.
your app could test the version of glibc being used and exit if not
recent enough. i'd think users of systems with known buggy glibc's
would want to upgrade anyway.
if dl* is available to you from a statically linked app (i think it
is when using libltdl), you could try implementing a wrapper for
gethostbyname() which invokes the dynamic glibc version. not sure
if this will really work because the ctor's for glibc will run too
late (after the program has already begun execution). even if it
works it may be too fragile.
lastly, you could give up on linux. :)
-frank
| |
| Casper H.S. Dik 2008-01-21, 7:28 pm |
| Rich Teer <rich.teer@rite-group.com> writes:
>On Mon, 21 Jan 2008, Dom Fulton wrote:
[color=darkred]
>Statically linking with system libraries isn't possible on Solaris,
>because the .a archive files don't exist. Dynamic linking is the
>only way.
Since Solaris 10 (32 bit static libraries existed until Solaris 9
or so; it stopped with new libthread, IIRC) Never did 64 bit
static libs, never did nsswitch statically (or anything else
pluggable)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Rainer Weikusat 2008-01-21, 7:28 pm |
| Frank Cusack <fcusack@fcusack.com> writes:
> On Mon, 21 Jan 2008 14:19:01 +0000 Dom Fulton <wes104@yahoo.com> wrote:
>
> if you know where the bugs are, you could reimplement those parts of
> glibc yourself to guarantee correctness.
Or to guarantee that random, undocumented properties of the used library
code would be identical to the random, undocumented properties of the
library code the application was developed with. This would depend on
what those hypothetical bugs actually are.
[...]
> lastly, you could give up on linux. :)
'Linux' is a kernel and does not include a C-library. Consequently,
this should be 'give up on GNU' instead (or 'give up on trying to cope
with the multitude of ways commercial Linux-distributors integrate
parts of GNU').
| |
| David Schwartz 2008-01-21, 7:28 pm |
| On Jan 21, 6:19 am, Dom Fulton <wes...@yahoo.com> wrote:
> I've got an app which I need to link statically for production use, so
> that users aren't faced with interminable dependency issues. The
> problem is that it uses 'gethostbyname' (and possibly other routines)
> which, it seems, can't be statically linked against. On Linux, I get a
> warning:
What you are asking to do is more or less impossible by design. Why
not code your own equivalent of the "gethostbyname" function that does
what you want? The definition of Linux's "gethostbyname" function is
basically: get a host record by name using
whatever mechanism the administrator of this system has configured.
If you know you want DNS, then write your own function to use DNS to
get the record. If you know you want to check /etc/hosts and then use
DNS, write your own function to do that.
But as "gethostbyname" is defined, it can only be performed by dynamic
libraries on the system.
DS
| |
| Frank Cusack 2008-01-21, 7:28 pm |
| On Mon, 21 Jan 2008 21:56:37 +0100 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Frank Cusack <fcusack@fcusack.com> writes:
>
> 'Linux' is a kernel and does not include a C-library. Consequently,
> this should be 'give up on GNU' instead (or 'give up on trying to cope
> with the multitude of ways commercial Linux-distributors integrate
> parts of GNU').
Indeed. How silly of me to get this wrong, since I usually correct
people myself who conflate the two.
-frank
| |
| Henry Townsend 2008-01-21, 10:24 pm |
| No one else has addressed the license implications. Since glibc is LGPL,
linking to it statically brings the linked program under the GPL too.
This is stated within the LGPL. So if your app is not GPL, you do not
want to link to glibc statically even if it's technically possible.
HT
| |
| George Peter Staplin 2008-01-21, 10:24 pm |
| ["Followup-To:" header set to comp.unix.programmer.]
Henry Townsend wrote:
> No one else has addressed the license implications. Since glibc is LGPL,
> linking to it statically brings the linked program under the GPL too.
> This is stated within the LGPL. So if your app is not GPL, you do not
> want to link to glibc statically even if it's technically possible.
>
> HT
As far as I know that's only true if the library is GPL.
http://www.gnu.org/licenses/lgpl-3.0.txt
Granted, it still makes distribution a pain in the ass for proprietary
software.
George
| |
| George Peter Staplin 2008-01-21, 10:24 pm |
| Dom Fulton wrote:
> I've got an app which I need to link statically for production use, so
> that users aren't faced with interminable dependency issues. The
> problem is that it uses 'gethostbyname' (and possibly other routines)
> which, it seems, can't be statically linked against. On Linux, I get a
> warning:
>
>
> The Linux nsswitch.conf(5) says:
>
>
> Well, excuse me, but requiring a user to have the same glibc version
> that the developer used for static linking is, in my book, much the
> same as saying that you can't link statically on Linux either.
>
> Any ideas on workarounds in Linux? This app shows up bugs in various
> glibc distributions, so dynamic linking isn't an option.
>
> Is the man page correct about Solaris? I guess that I could link
> dynamically on Solaris, given that anyone using the code will be on
> Solaris 10.
I think this answers your questions pretty well about glibc for Linux:
http://www.gnu.org/software/libc/FAQ.html#s-2.22
George
| |
| William Ahern 2008-01-21, 10:24 pm |
| Henry Townsend <henry.townsend@not.here> wrote:
> No one else has addressed the license implications. Since glibc is LGPL,
> linking to it statically brings the linked program under the GPL too.
This is false.
<snip>
> So if your app is not GPL, you do not want to link to glibc statically
> even if it's technically possible.
Maybe, maybe not. There are certainly options, one of which permits keeping
source code private. Note, for instance, Clause 6(a), taken from
COPYING.LIB, distributed with the latest glibc stable tarball:
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered
by this License. You must supply a copy of this License. If the
work during execution displays copyright notices, you must include
the copyright notice for the Library among them, as well as a
reference directing the user to the copy of this License. Also, you
must do one of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including
whatever changes were used in the work (which must be
distributed under Sections 1 and 2 above); and, if the work
is an executable linked with the Library, with the complete
machine-readable "work that uses the Library", as object
code and/or source code, so that the user can modify the
Library and then relink to produce a modified executable
containing the modified Library. (It is understood that the
user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the
application to use the modified definitions.)
...
| |
| Dom Fulton 2008-01-25, 7:20 pm |
| On Mon, 21 Jan 2008 22:06:16 -0500, Henry Townsend
<henry.townsend@not.here> wrote:
>No one else has addressed the license implications. Since glibc is LGPL,
>linking to it statically brings the linked program under the GPL too.
>This is stated within the LGPL. So if your app is not GPL, you do not
>want to link to glibc statically even if it's technically possible.
I have to confess that I thought glibc was somehow exempt; I thought
only the crazies put this in their own modified LGPLs. Do these guys
ever wonder why Linux still has < 1% of desktop share? Clearly not.
It's all the more bizarre when you consider that I only want to link
statically because shared-lib code has such poor portability on Linux
platforms.
My own reading of section 4d of the LGPL is that I can link
statically, as long as I also distribute something that the end-user
can link against a different version of libc.a. Completely pointless,
but I think that would be enough to comply with the license. Some
Googling also shows lots of different opinions on whether the
static/dynamic issue is actually relevant.
- Dom
| |
| Dom Fulton 2008-01-25, 7:20 pm |
| That seems to say much the same as 4.d)0) in
http://www.gnu.org/copyleft/lesser.html. The real license seems to be
less restrictive, though - it doesn't say anything about distributing
the source code for the library.
- Dom
| |
| Rainer Weikusat 2008-01-25, 7:20 pm |
| Dom Fulton <wes104@yahoo.com> writes:
> On Mon, 21 Jan 2008 22:06:16 -0500, Henry Townsend
> <henry.townsend@not.here> wrote:
>
> I have to confess that I thought glibc was somehow exempt; I thought
> only the crazies put this in their own modified LGPLs. Do these guys
> ever wonder why Linux still has < 1% of desktop share?
The nowadays usually published numbers would be somewhat (or even a
lot) more than '< 1 %', heavily depending on whom you ask. And this
corresponds with a really larger number of computers (and computer
users).
> Clearly not. It's all the more bizarre when you consider that I only
> want to link statically because shared-lib code has such poor
> portability on Linux platforms.
You have until now failed to provide an example of exactly what
problems you are experiencing and until you do, I will, taking
personal experience from more than the last ten years into account,
rather assume that the problems rests on your side. The last real
issue wrt glibc shared library incompatiblity was introduced by
switching to symbol versioning, and the idea behind this was to
enhance compatiblity in future. This took place quite some time ago
(more than five years).
BTW, could you please kill this stupid crosspost to a Solaris group?
| |
| Frank Cusack 2008-01-25, 7:20 pm |
| On Fri, 25 Jan 2008 16:28:00 +0000 Dom Fulton <wes104@yahoo.com> wrote:
> I have to confess that I thought glibc was somehow exempt; I thought
> only the crazies put this in their own modified LGPLs. Do these guys
> ever wonder why Linux still has < 1% of desktop share? Clearly not.
The license has no bearing on Linux desktop penetration. The vast
majority of end users care not a whit about the license (as evidenced
by the VAST majority of Windows and MacOS users who agree to EULA
terms which are pretty outrageous, as well as the great great numbers
of Linux desktop users willing to use proprietary graphics card
drivers), and the vast majority of developers are perfectly fine
with shared libraries on Linux systems, thereby rendering the license
terms of Linux (and glibc, etc.) itself moot to their application.
-frank
|
|
|
|
|