empty lib*.a files

empty lib*.a files

[Daniel Cegiełka]

Hi,
correct me :)

# ls
Scrt1.o              ld-musl-x86_64.so.1  libdl.a              librt.a
crt1.o               libc.a               libm.a               libutil.a
crti.o               libc.so              libpthread.a         libxnet.a
crtn.o               libcrypt.a           libresolv.a
#
# ar t libm.a
# ar t libcrypt.a
# ar t libpthread.a
#
# ar t libc.a | grep fabs
fabs.o
fabsf.o
fabsl.o
#

I made a standard installation (git).

regards,
daniel

Re: empty lib*.a files

[Gregor Richards]

On 07/24/12 16:11, Daniel Cegiełka wrote:
> Hi,
> correct me :)
>
> # ls
> Scrt1.o              ld-musl-x86_64.so.1  libdl.a              librt.a
> crt1.o               libc.a               libm.a               libutil.a
> crti.o               libc.so              libpthread.a         libxnet.a
> crtn.o               libcrypt.a           libresolv.a
> #
> # ar t libm.a
> # ar t libcrypt.a
> # ar t libpthread.a
> #
> # ar t libc.a | grep fabs
> fabs.o
> fabsf.o
> fabsl.o
> #
>
> I made a standard installation (git).
>
> regards,
> daniel

musl puts everything in libc. The other libs are only present for 
compatibility with build scripts that are incapable of proper detection. 
They are, as it is said, intentionally left blank.

With valediction,
  - Gregor Richards

Re: empty lib*.a files

[Daniel Cegiełka]

> musl puts everything in libc. The other libs are only present for
> compatibility with build scripts that are incapable of proper detection.
> They are, as it is said, intentionally left blank.
>
> With valediction,
>  - Gregor Richards
>

thx, we had a lot of problems with crypt_blowfish in libc vs libcrypt :)

http://openwall.com/lists/musl/2012/07/21/1

daniel

Re: empty lib*.a files

[Rich Felker]

On Tue, Jul 24, 2012 at 10:33:18PM +0200, Daniel Cegiełka wrote:
> > musl puts everything in libc. The other libs are only present for
> > compatibility with build scripts that are incapable of proper detection.
> > They are, as it is said, intentionally left blank.
> >
> > With valediction,
> >  - Gregor Richards
> >
> 
> thx, we had a lot of problems with crypt_blowfish in libc vs libcrypt :)

To clarify, the reasons all of the standard library is integrated into
a single file mainly apply to dynamic linking:

1. Performance: Loading one shared library is faster than loading 3+
shared libraries. A modern multithreaded program is likely to use at
least libc, libm, libpthread, and librt.

2. Saving memory: Each additional shared library wastes at least one
page of commit charge and dirty physical memory, even though it will
probably just be for the GOT except in libc which needs a few pieces
of global data. Technically libm might be able to get by without a GOT
entirely, but I doubt the linker would make a GOT-free library even if
it technically could.

3. Avoiding exposing implementation internals and version
incompatibility: If libc/libm/libpthread/etc. are separate libraries,
they need cross-library references to implementation-internal
functions and data. This in turn can lead to bad breakage if there's a
version mismatch between them, and even worse, if a static version of
libm or libpthread got used with a dynamic libc, the binary would now
be permanently pegged to a particular version of libc due to using
impermanent internal interfaces specific to that version.

None of these issues apply if you're using static linking, but the
reason I also chose not to split up the static library files is the
same as the end of point 3 above: if libpthread.a contained static
versions of the pthread functions, it might get linked into a program
using dynamic libc.so, and introduce the version lock-in described
above. To avoid this, we'd have to make sure a file named
libpthread.so existed as a no-op linker script (if it existed as an
empty ELF shared library file, it might get added to the program's
DT_NEEDED and then points 1 and 2 above would apply).

Since there's no benefit to separating the standard library into
broken-down .a files, and lots of potential pitfalls, I chose not to
separate it for static linking either.

As for why the empty .a files exist, it's because POSIX requires -lm,
-lpthread, etc. to be valid options to the C compiler, and requires
portable programs to use these options in their build scripts even if
the implementation does not require them. Making empty .a files is the
easiest way to meet that requirement.

Rich