Hello

Our current -static packages were rushed in without much testing and
prototyping and are suboptimal.

First, abuild has no automatic dependency tracking like -dev has by
tracking the 'Requires:' field from pkg-config and handling solinks.

This means that every -static subpackage which requires another package
to link will fail to link.

As an example: I faced it with libgit2 while working on 'agl',
installing libgit2-static wasn't enough I had to install openssl-libs-
static, http-parser-static, etc separately while they should be
installed all at once when I requested libgit2-static.

Considering Alpine Linux uses a very static-linking friendly musl and
statically linking is actually feasible and done in some places (apk-
tools-static, busybox-static) I think it is important that doing it
actually works seamlessly for the user (and us).

Second, the size reduction is minimal for the -dev package, and -dev
packages aren't really expected to be small.

Third, the benefit of avoiding accidental linking has materialized (at
least for me) only once when upgrading the skarnet suite of tools.

While it is a nice benefit it doesn't happen often enough or is not
apparent enough when maintaing packages in aports.

My proposals are:

1. Remove -static subpackages and move the static library to -dev, if
backwards compat is a concern we can make `-dev` provides= and
replaces= `-static` too.
2. Avoid using --disable-static or removing the static library with
'rm' and respect the upstream decision to build it by default or not.

Regards
Leo

maxice8 <thinkabit.ukim@gmail.com> wrote:
> Hello

Hi,

> First, abuild has no automatic dependency tracking like -dev has by
> tracking the 'Requires:' field from pkg-config and handling solinks.
> 
> This means that every -static subpackage which requires another package
> to link will fail to link.

Yep, I ran into this issue quite a few times myself.

> My proposals are:
> 
> 1. Remove -static subpackages and move the static library to -dev, if
> backwards compat is a concern we can make `-dev` provides= and
> replaces= `-static` too.
> 2. Avoid using --disable-static or removing the static library with
> 'rm' and respect the upstream decision to build it by default or not.

Sounds good to me, never really liked the -static split in the first place.

Cheers,
Sören

Hi Leo,

maxice8:
> My proposals are:
> 
> 1. Remove -static subpackages and move the static library to -dev, if
> backwards compat is a concern we can make `-dev` provides= and
> replaces= `-static` too.

just to be sure, you are only talking about removing -static subpackages 
for libraries, right?

I want to be sure whether apk-tools-static stays around, as we're using 
this with pmbootstrap (and I'm sure that there are lots of other scripts 
using it to bootstrap alpine systems).

Best,
Oliver

> just to be sure, you are only talking about removing -static
subpackages 
for libraries, right?

yes, the only -static packages that will be gone are those that hold
static libraries (.a).

On Sat, 2021-01-16 at 03:28 -0300, maxice8 wrote:
> Hello
> 
> [...]
> 
> My proposals are:
> 
> 1. Remove -static subpackages and move the static library to -dev, if
> backwards compat is a concern we can make `-dev` provides= and
> replaces= `-static` too.

+1 on that. We should also trace dependencies for static libs via
`Requires.Private` to make sure we pull in the right pc:* packages.

> 2. Avoid using --disable-static or removing the static library with
> 'rm' and respect the upstream decision to build it by default or 

IMHO we should just enable static libs for packages where it's not too
expensive so users don't have to make a Gitlab issue for when they need
static libs too often.

Regards,

Rasmus Thomsen

> Regards
> Leo
> 

On Sun, 2021-01-17 at 22:51 +0100, Rasmus Thomsen wrote:
> On Sat, 2021-01-16 at 03:28 -0300, maxice8 wrote:
> > Hello
> > 
> > [...]
> > 
> > My proposals are:
> > 
> > 1. Remove -static subpackages and move the static library to -dev,
> > if
> > backwards compat is a concern we can make `-dev` provides= and
> > replaces= `-static` too.
> 
> +1 on that. We should also trace dependencies for static libs via
> `Requires.Private` to make sure we pull in the right pc:* packages.
> 

Good news is that is already done via --print-requires-private, see
abuild.in[1].

> > 2. Avoid using --disable-static or removing the static library with
> > 'rm' and respect the upstream decision to build it by default or 
> 
> IMHO we should just enable static libs for packages where it's not
> too
> expensive so users don't have to make a Gitlab issue for when they
> need
> static libs too often.
> 

I have no interest in hunting down whichever packages are expensive or
not to enable static libraries, I prefer to wait for them to make a
GitLab issue or ask for it on IRC (should be friendly enough, everyone
can hop on IRC via a webclient and just ask for it).

That said if someone wants to go through the process of quantifying
`expensive` and enabling on those that do not qualify as `expensive`,
go for it.

At the most **extreme** I would encourage enabling static libraries by
making `--disable-static` and equivalents on other build-systems a
`MINOR` policy violation in atools.

> Regards,
> 
> Rasmus Thomsen
> 
> > Regards
> > Leo
> > 
> 

[1]:
https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1586

On Sat, 16 Jan 2021 03:28:08 -0300
maxice8 <thinkabit.ukim@gmail.com> wrote:

> Hello
> 
> Our current -static packages were rushed in without much testing and
> prototyping and are suboptimal.
> 
> First, abuild has no automatic dependency tracking like -dev has by
> tracking the 'Requires:' field from pkg-config and handling solinks.
> 
> This means that every -static subpackage which requires another package
> to link will fail to link.
> 
> As an example: I faced it with libgit2 while working on 'agl',
> installing libgit2-static wasn't enough I had to install openssl-libs-
> static, http-parser-static, etc separately while they should be
> installed all at once when I requested libgit2-static.
> 
> Considering Alpine Linux uses a very static-linking friendly musl and
> statically linking is actually feasible and done in some places (apk-
> tools-static, busybox-static) I think it is important that doing it
> actually works seamlessly for the user (and us).

My thinking is that we don't really support static linking for our own
packages. We should always use dynamic linking, with a few exceptions.
(like qemu user). But we can provide -static when requested and it does
not cost us much.

> Second, the size reduction is minimal for the -dev package, and -dev
> packages aren't really expected to be small.
>
> Third, the benefit of avoiding accidental linking has materialized (at
> least for me) only once when upgrading the skarnet suite of tools.
> 
> While it is a nice benefit it doesn't happen often enough or is not
> apparent enough when maintaing packages in aports.
> 
> My proposals are:
> 
> 1. Remove -static subpackages and move the static library to -dev, if
> backwards compat is a concern we can make `-dev` provides= and
> replaces= `-static` too.

The main reason we want have a separate -static package is to avoid
accidentally link to static library. By having it in separate package
you need to explicitly install it, or you will get dynamic linking.

Second reason is that we normally don't need the static libraries so
its just bloat. In most cases it does not matter install 3MB extra, but
IMHO its just waste. Some of the static packages do have significant
size. llvm10-static for example, is 189MB.

> 2. Avoid using --disable-static or removing the static library with
> 'rm' and respect the upstream decision to build it by default or not.

I think we should use --disable-static as the default, and enable
static on request. We shouldn't use the static library ourselves (with
a few exceptions), but can make it available when someone asks for it.


> 
> Regards
> Leo
> 

On Tue, 2021-01-19 at 21:27 +0100, Natanael Copa wrote:
> On Sat, 16 Jan 2021 03:28:08 -0300
> maxice8 <thinkabit.ukim@gmail.com> wrote:
> 
> > Hello
> > 
> > Our current -static packages were rushed in without much testing
> > and
> > prototyping and are suboptimal.
> > 
> > First, abuild has no automatic dependency tracking like -dev has by
> > tracking the 'Requires:' field from pkg-config and handling
> > solinks.
> > 
> > This means that every -static subpackage which requires another
> > package
> > to link will fail to link.
> > 
> > As an example: I faced it with libgit2 while working on 'agl',
> > installing libgit2-static wasn't enough I had to install openssl-
> > libs-
> > static, http-parser-static, etc separately while they should be
> > installed all at once when I requested libgit2-static.
> > 
> > Considering Alpine Linux uses a very static-linking friendly musl
> > and
> > statically linking is actually feasible and done in some places
> > (apk-
> > tools-static, busybox-static) I think it is important that doing it
> > actually works seamlessly for the user (and us).
> 
> My thinking is that we don't really support static linking for our
> own
> packages. We should always use dynamic linking, with a few
> exceptions.
> (like qemu user). But we can provide -static when requested and it
> does
> not cost us much.
> 

Yes.

> > Second, the size reduction is minimal for the -dev package, and -
> > dev
> > packages aren't really expected to be small.
> > 
> > Third, the benefit of avoiding accidental linking has materialized
> > (at
> > least for me) only once when upgrading the skarnet suite of tools.
> > 
> > While it is a nice benefit it doesn't happen often enough or is not
> > apparent enough when maintaing packages in aports.
> > 
> > My proposals are:
> > 
> > 1. Remove -static subpackages and move the static library to -dev,
> > if
> > backwards compat is a concern we can make `-dev` provides= and
> > replaces= `-static` too.
> 
> The main reason we want have a separate -static package is to avoid
> accidentally link to static library. By having it in separate package
> you need to explicitly install it, or you will get dynamic linking.
> 

The split has helped me only once, while dealing with skarnet software
suite, I don't think it is worth it to have a broken -static package
that can't even be used ootb to link statically.

> Second reason is that we normally don't need the static libraries so
> its just bloat. In most cases it does not matter install 3MB extra,
> but
> IMHO its just waste. Some of the static packages do have significant
> size. llvm10-static for example, is 189MB.
> 

It is bloat part of the -dev subpackage which I don't consider as
important as avoiding bloat in the main packages (which we expect users
to install in the containers permanently) most users install -dev and
then remove it after compiling the final binary for their docker
containers.

> > 2. Avoid using --disable-static or removing the static library with
> > 'rm' and respect the upstream decision to build it by default or
> > not.
> 
> I think we should use --disable-static as the default, and enable
> static on request. We shouldn't use the static library ourselves
> (with
> a few exceptions), but can make it available when someone asks for
> it.
> 

I prefer letting upstream decide if they want or not, if they(upstream)
compile a static library then don't mess with it, if they don't then
enable **only** if someone requires it.

> 
> > 
> > Regards
> > Leo
> > 
> 

>The split has helped me only once, while dealing with skarnet software
>suite, I don't think it is worth it to have a broken -static package
>that can't even be used ootb to link statically.

  I find it difficult to believe that my software has to be treated
differently from others. Could you please explain why and how -static
helped you with my software when it did not with other packages?

  I have no opinion on having -static packages or not, as long as
static libraries are made available in -dev if there is no -static.
It is important to allow developers and packagers to use static
libraries if they so choose.

  skarnet.org software uses static libraries by default, because
it's small enough that doing so actually ends up in less RAM usage.
In some cases (like utmps), the .a is actually *smaller* than the
.so, so using a shared library really doesn't make sense from a
resource usage standpoint.
  However, it can be trivially configured to use shared libraries
instead: --disable-allstatic. This flag is present in all my
APKBUILDs, to follow Alpine policy; and a policy change, or an
alternative build, is just a matter of commenting the flag.

  I don't understand the "broken -static package that can't even be
used ootb to link statically" part. Doesn't abuild create actually
functional -static packages?

--
  Laurent

Hi,

Natanael Copa <ncopa@alpinelinux.org> wrote:
> My thinking is that we don't really support static linking for our own
> packages. We should always use dynamic linking, with a few exceptions.
> (like qemu user). But we can provide -static when requested and it does
> not cost us much.

I agree that we don't need to support static linking for our own
packages. However, I think many people rely on us providing static
libraries. I have seen quite a few Docker images using Alpine to build
statically linked versions of OSS software. From the top of my head, the
vis text editor uses Alpine for this purpose [1].

I also have quite a bit of software lying around which I link statically
on Alpine in order to be able to use recent versions of it on ancient
non-Alpine server systems (shells, text editors, …).

> I think we should use --disable-static as the default, and enable
> static on request. We shouldn't use the static library ourselves (with
> a few exceptions), but can make it available when someone asks for it.

I think we should support static linking of packaged
libraries for the use cases outlined above. Also consider that musl has
some obvious advantage over glibc in regards to static linking, thereby
making Alpine a very decent choice for these use cases.

Greetings,
Sören

[1]: https://github.com/martanne/vis/blob/master/Dockerfile