Re: Create libFOO.a from libFOO.so?

Scott <ss@xxxxxxxxxxxxxxxx> writes:

If your static binary (or any of the libraries you link with
it) calls any number of libc routines, such as gethostname(),
getdomainname(), getpwuid(), etc., that binary will either not work
correctly, or crash when executed on arbitrary Linux system.

What is the reason for that?

The 'glibc' is actually a tightly bound nest of binaries which all
know each others internals and have undocumented and changing binary
interfaces between them.

For the static linking case, the problem is that e.g. getpwuid()
needs to work with DNS, NIS, LDAP etc, and the easiest way to get
there is to use dynamically loaded code from /lib/libnss*

That code is dynamically loaded whether you link your executable
statically or dynamically against libc. If you link statically, the
code from libc.a which is now part of your executable will still
use undocumented/private/binary interface to libnss*, and this may
crash if the interface libc.a expects does not match the interface
libnss* provides.

I'm
genuinely interested in finding out why a .so to .a (or .o)
conversion program is "non-trivial". Just for my own understanding.

The best way to understand this is to write one :)

From what you're saying, it appears statically-linked
binaries are actually _less_ portable (than a dynamically-linked binary
distributed with all dependent shared object libraries).

That is generally true for all modern UNIXes -- e.g. Solaris7
binaries are "guaranteed" to work on Solaris 8,9,10 *provided*
the binary is dynamically linked against system libraries.

If the Solaris7 binary is statically linked, all bets are off.

I accept that someone has to go to all of the trouble of understanding
the formats of .so & .o files & working out how to do some sort of
UNsubstitution. But I don't understand the technical reasons that
prohibit a reliable .so to .o conversion program.

There is no reason this conversion can't be done reliably.

The reason this is non-trivial is that DSO is arranged such that
it *requires* the dynamic loaders' assistance to become fully
operational. You could "undo" this, but it is not very easy.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
.

Relevant Pages

  • Sid Meiers Railroads tentative patch list
    ... AI - Fix for AI failing to set a route in first minute of game. ... AI - Refresh mission status after each train added (ensures early ... Crash - Deleting both routes to a train will no longer crash the ... don't try to update the main game interface ...
    (comp.sys.ibm.pc.games.strategic)
  • Re: Sid Meiers Railroads tentative patch list
    ... AI - Fix for AI failing to set a route in first minute of game. ... AI - Refresh mission status after each train added (ensures early ... Crash - Deleting both routes to a train will no longer crash the ... don't try to update the main game interface ...
    (comp.sys.ibm.pc.games.strategic)
  • Re: Does Python really follow its philosophy of "Readability counts"?
    ... Separating an interface from its implementation reduces the ... whatever reason, it's unwilling to reveal to me. ... And `enforced data hiding' just slams ... Irrelevant for read-only inspection. ...
    (comp.lang.python)
  • RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?
    ... kernel. ... A process has unity of interface. ... you cannot conjoin-clone and thread-clone repeatedly and variously from the ... If there is no reason to share, ...
    (Linux-Kernel)
  • Re: WinXP 64-bit Virtual DMA_ADAPTER
    ... Such interface abstracts from any internal implementation ... system that runs without Verifier. ... If MSFT wants a black box OS, ... reason why it should work differently under 64. ...
    (microsoft.public.development.device.drivers)