Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Tomasz Kłoczko]

Despite such simple to fix bug using static libraries should be removed.
Your comment makes me wonder if there is *any* appropriate use of
boost-static. If not, why is it even packaged?
I'd be happy to accept your help patching what upstream is doing to move
from boost-static to boost-test (I'm not sufficiently knowledgeable about
C/C++ tooling to switch on my own), but since the dependency is limited to
unit testing during the build, I think it's probably fine.

This problem is waaaay bigger than you may be thinking. Above it is only
tip of the iceberg ..

# dnf list | grep -- -static | grep -c x86_64

196

(above is against rawhide)
and this is not all because some static libraries are scattered across some
non-static subpackages.

One of the most bizarre IMO static packages is glibc-static.
This package is produced only because (IIRC) binutils in set of tests
executed in %check does some test against linking with -static. However
those tests are not done against some test.a library but thyey wants to use
libc.a.
By this compilation of the glibc package is probably almost two times
longer than it could be.
Some people seems are really trying to follow blindly some processes
defined in some build frameworks without thinking does it make any sense to
follow what was original defined.

For example Solaris 11 userland which is using exactly the the same version
of binutils as current fedora rawhide has disabled these test .. because
Solaris does not provide (at all almost two decades) libc.a and Solaris ABI
guideline does not recommend link any user space programs against static
libraries if it is only possible.

If package like glibc-static will be still propagated to commercial RH
sooner or later it will blow up into the face RH support as some customer
will have some issue with some his own binary linked against some ancient
version of glibc static library still used on some quite fresh distro
resources (a little more than year ago I had case when production Linux
based on OL 6 was still using binary program statically linked 10 years
ago, and yes .. this binary was even "correctly" packaged into regular rpm
package :) ).

Solutions:

1) Of course get rid of *ALL* -static packages with all roots like this one
in binutils.

2) Probably it would be not so bad to add at the end of rpms package
assembly process print kind of big warning that someone is trying to build
package which will provide static libraries.

3) Another idea of some long term solution consider to implement.
Add in %prep post script checking are any of configure.{in.ac} files
contains AC_ENABLE_STATIC aclocal macro and recommend push to original
source tree change this to AC_DIABLE_STATIC and/or at least make sure that
in %build in %configure parameters is s used --disable-static.

kloczek

[Richard W.M. Jones]

Post by Tomasz Kłoczko

Despite such simple to fix bug using static libraries should be removed.
Your comment makes me wonder if there is *any* appropriate use of
boost-static. If not, why is it even packaged?
I'd be happy to accept your help patching what upstream is doing to move
from boost-static to boost-test (I'm not sufficiently knowledgeable about
C/C++ tooling to switch on my own), but since the dependency is limited to
unit testing during the build, I think it's probably fine.

This problem is waaaay bigger than you may be thinking. Above it is only
tip of the iceberg ..
# dnf list | grep -- -static | grep -c x86_64
196

The problem being what exactly?

Post by Tomasz Kłoczko
One of the most bizarre IMO static packages is glibc-static.

The problem being what exactly?

Post by Tomasz Kłoczko
By this compilation of the glibc package is probably almost two times
longer than it could be.

OK, so we suffer that problem only once (during the glibc build). But
it's a benefit to have glibc-static because it enables people to build
staticly linked programs.

These are very useful for building embedded systems, initramfses,
static linked binaries of large proprietary programs, and any case
where you don't want to depend on the system libraries.

Post by Tomasz Kłoczko
If package like glibc-static will be still propagated to commercial RH
sooner or later it will blow up into the face RH support as some customer
will have some issue with some his own binary linked against some ancient
version of glibc static library still used on some quite fresh distro
resources

It's nice that you're thinking so much about Red Hat and their support
problems, but I think Red Hat can deal with that themselves. In the
case you describe it wouldn't be a supported configuration and there
would be no support issues.

Post by Tomasz Kłoczko
1) Of course get rid of *ALL* -static packages with all roots like this one
in binutils.

That's a terrible idea.

Post by Tomasz Kłoczko
2) Probably it would be not so bad to add at the end of rpms package
assembly process print kind of big warning that someone is trying to build
package which will provide static libraries.

Also a terrible idea. Static libraries are useful in several
situations, and we should not disable this capability.

Rich.

[Jonathan Wakely]

Post by Richard W.M. Jones

Post by Tomasz Kłoczko

Despite such simple to fix bug using static libraries should be removed.
Your comment makes me wonder if there is *any* appropriate use of
boost-static. If not, why is it even packaged?
I'd be happy to accept your help patching what upstream is doing to move
from boost-static to boost-test (I'm not sufficiently knowledgeable about
C/C++ tooling to switch on my own), but since the dependency is limited to
unit testing during the build, I think it's probably fine.

This problem is waaaay bigger than you may be thinking. Above it is only
tip of the iceberg ..
# dnf list | grep -- -static | grep -c x86_64
196

The problem being what exactly?

Post by Tomasz Kłoczko
One of the most bizarre IMO static packages is glibc-static.

The problem being what exactly?

Post by Tomasz Kłoczko
By this compilation of the glibc package is probably almost two times
longer than it could be.

OK, so we suffer that problem only once (during the glibc build). But
it's a benefit to have glibc-static because it enables people to build
staticly linked programs.
These are very useful for building embedded systems, initramfses,
static linked binaries of large proprietary programs, and any case
where you don't want to depend on the system libraries.

Post by Tomasz Kłoczko
If package like glibc-static will be still propagated to commercial RH
sooner or later it will blow up into the face RH support as some customer
will have some issue with some his own binary linked against some ancient
version of glibc static library still used on some quite fresh distro
resources

It's nice that you're thinking so much about Red Hat and their support
problems, but I think Red Hat can deal with that themselves. In the
case you describe it wouldn't be a supported configuration and there
would be no support issues.

If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deve

[Tomasz Kłoczko]

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impression that this part is already covered in
support conditions.

Again try to answer on question why long time ago other OSes abandoned
providing static libc?
Internally this part is and always will be affected by definition by any
future changes in kernel ABI. glibc it is not only libc library. Glibc
provides couple of other components which are using internal glibc ABI/API.
Shared libc wraps all those changes and allows handle (in long term) even
quite significant changes beneath own glibc public API/ABI and on boundary
between kernel<->user space without hurting user space binaries.

And one more clarification: remove static libraries from glibc distro
packages does not blocks static linking.
It will only removes possibility linking against static glibc libraries.

Remove static libc it is not new idea. It is +20 years around and none of
the Solaris users moved away from this OS by this reason.
No .. it is completely opposite situation. Because OS like Solaris does not
provides libc.a still even on latest Solaris is possible execute and use
more than decade old binaries.

Linux kernel ABI is changing constantly and flexibility on boundary between
kernel and userspace is covered in Linux kernel documentation *literally*.
From Documentation/ABI/README:

stable/
This directory documents the interfaces that the developer has
defined to be stable. Userspace programs are free to use these
interfaces with no restrictions, and backward compatibility for
them will be *guaranteed for at least 2 years*. Most interfaces
(like syscalls) are expected to never change and always be
available.


Possibility of future changes between kernel and user space was even one of
the fundamental reasons why libc was developed looog time ago before Linus
started thinking about porting Minix to i386.

You can ignore me but you cannot ignore facts behind why something like
libc exist and why no one should use static version of the libc libraries.

Especially static linking with glibc is very dangerous as long if linked
binary is using NSS libc interface. Some people are thinking that "fully"
statically linked program does not use or will not need any DSOs. In case
of using by such binary NSS libc interface this not true as depends on NSS
map type and NSS settings (described in /etc/nsswitch.conf) will be causing
loading nss_<foo>.so DSOs.
Number of changes in glibc in internal NSS interface where quite big in
recent years, and if someone will/is using statically linked binary where
NSS interface is in use such binary will be loading NSS modules (probably)
compiled against not correct glibc.Result: execution of such binaries will
fail or even crash with SIGSEV.
This scenario is covered literally as well in glibc documentation:
https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

It is already known that within next few years NSS area in glibc it will be
probably one of the fastest changing area in glibc whole project. Solaris
already coverers in his own libc many NSS security related extensions.
Glibc has a lot to catch up here. All those upcoming changes will
definitely even harder kick back all people linking own executables against
glibc static libraries. This will be probably even bigger problem than all
potential kernel<->user space ABI changes.

Other static libraries used by distribution are carrying as well real and
potential security risk.
Example: RH/Fedora is using bash which is linked against own copy of
readline (provided within bash original source tree). It was few CVEs in
readline in recent years and some people been exploiting fact that bash
was/is linked against readline with well known security issue.
So here is surprise: in case finding new 0-day bug(s) in readline it will
be necessary to provide not one readline fixed package but two .. readline
and bash.

Yes. RH/Fedora bash has some *very well known security flaw* which hanging
above whole distro reputation like a Damocles sword!!!
In last 20 years I've been trying to convince few people to remove exactly
this bash risk but last time when I've been trying this my English was not
good enough to express this enough clear and strong. Maybe this time ..

Reality is that remove building and providing all of those +190 -static
packages will as well allow save a lot of CPU time on Fedora build systems.
I'm 100% sure that no one is using those static libraries and they are
build and packaged only because some project source trees default settings
are building those static libraries. That is only reason why those .a files
are still flying around!!!
And yet another fact: in last decade number of packages providing static
copies of some libraries decreased few times (only in RH distribution).
This is because there are more tan few people aware that building packaging
those files is pointless.

Controlling internal entropy and keeping it on lowest possible level on
whole distro level should be everyone goal as well :)

Summarising. There are at least three reasons why static libraries should
be completely removed from distribution:
1) Constant ABI changes
2) Security risk
3) Waste of time/resources on building and providing static libraries

kloczek

[Florian Weimer]

Post by Tomasz Kłoczko
So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100%
sure that exactly this part is not in RH support small prints. In other
words you may have only impression that this part is already covered in
support conditions.

A statically linked libc isn't much different from a dynamically linked
libc in a container. Both rely on stable kernel interfaces. Same for
alternative toolchains not based on GNU.

The main problem with static linking in Fedora is that we do not rebuild
all static libraries once we update glibc-static. glibc only provides
ABI compatibility for dynamic linking. The only saving grace is that we
gradually cut back on the use of compatibility symbols to make header
file changes, so incompatible changes have been quite rare for a while.

This isn't really glibc-specific, though, it probably applies to other
static libraries, too. The impact of changes to glibc-static are just
more visible.

Post by Tomasz Kłoczko
Again try to answer on question why long time ago other OSes abandoned
providing static libc?

I think those other operating systems simply do not expose internal
development tools externally. They still use static linking in some places.

Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@list

[Tomasz Kłoczko]

On 15 March 2017 at 14:16, Florian Weimer <***@redhat.com> wrote:
[..]

Post by Florian Weimer
The main problem with static linking in Fedora is that we do not rebuild
all static libraries once we update glibc-static. glibc only provides ABI
compatibility for dynamic linking. The only saving grace is that we
gradually cut back on the use of compatibility symbols to make header file
changes, so incompatible changes have been quite rare for a while.
This isn't really glibc-specific, though, it probably applies to other
static libraries, too. The impact of changes to glibc-static are just more
visible.
Again try to answer on question why long time ago other OSes abandoned

Post by Tomasz Kłoczko
providing static libc?

I think those other operating systems simply do not expose internal
development tools externally. They still use static linking in some places.

You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.
Trying to crush what you are thinking about subject using stronger phrases
would illogical and I'm not going to follow this path. Really pleas try to
stick to technical arguments.
Discussion it is like fencing but using arguments. It is really hard try to
convince someone using what "I think". Look again on what I've already
wrote and you will find that none of my argumentation relies on what "I'm
thinking".

Again: there was already enough bad cases in Unix history to form
conclusion that none of the regular distribution consumers should rely on
things below libc public ABI/API because unconsciously using such parts
they been doing for themselves more harm than real financial/reputation or
other damages to anyone who is trying to provide commercial or
non-commercial support of any OS distribution.

I'll try to rephrase above. In the past I've been working on whole rpm
based distribution and more than decade ago I made decision about separate
all static libraries into -static subpackages. After what we (me and few my
colleagues) done other distros started mimicking this pattern. It was done
consequently on scale +6k source packages (used by ~few thousands end
users) and after this I found that it was none real case scenario where
those static packages are really needed.
Look on what is now in Fedora and you will find that binutils has some
quite strange or easy to handle other way modifications in spec file only
to fully follow what is in source code binutils test suit.

What I've personally tested long time ago still stands firmly against you
honest impression (that such resources still may be good to have around in
form of packages).
In other words: what you see now in distribution like Fedora like some
-static subpackages it is because what I've personally started more than
decade ago.
IMO now is enough good sample of using such approach (separating static
libraries) to form conclusion that this was kind of mistake and all those
static libraries can be dropped without any noticeable consequences .. on
even some hard/nasty developers oriented install profiles.

With all what you are trying (honestly) to tell is like with some aspects
of quantum physics which says that probability that bucket of water
standing on top of open fire may freeze is non-zero.
Problem is that in real word maintained by real engineers it is really hard
to observe something like this :)
Many years ago I've been thinking just like you because same like you I've
been using intuition.
Trust me. If you are still *thinking* that you are right, it may be really
truth .. that you are *only thinking* that you are right :)

kloczek

[Florian Weimer]

Post by Tomasz Kłoczko
You are not even trying to answer on above question .. a bit sad because
you are simple ignoring some very good technical arguments.

Please read again what I wrote.

In a container (and multi-toolchain) world, static linking of glibc does
not add a significant support burden because we cannot use glibc as an
abstraction layer for the kernel, unlike what other operating systems
do. (This is independently of what is actually supported.)

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe

[Tomasz Kłoczko]

Post by Florian Weimer
Please read again what I wrote.
In a container (and multi-toolchain) world, static linking of glibc does
not add a significant support burden because we cannot use glibc as an
abstraction layer for the kernel, unlike what other operating systems do.
(This is independently of what is actually supported.)

Please try to have look first on "dnf list | grep -- - static" list maybe
after this you will realise that current list of packages with static
libraries is not enough to have such static linking dev environment because *in
last years many packages already dropped building and packaging static
libraries,* and no one been crying by this.
For cases which will mainly require for some reasons static linking with
libc.a probably it would be good consider switch to uClibc because in such
cases size of the binaries probably is quite important.

I have no idea from where it comes but glibc never was and never will be
abstraction layer for the kernel on any existing operating systems because
kernel provides abstraction layer on which sits (g)libc.

I'm still greping across all packages repos but so far I found only two
fedora packages which requires during build glibc-static. One is binutils
and second one is golang. Both packages uses static linking in own test
suits.
To test binutils ld that it able to link elf binary or DSO using some test
static libraries you don't need to link such test binary with libc.a.

Will have shortly full assessment of what really is using in Fedora
glibc-static.

kloczek

[Jonathan Wakely]

Post by Tomasz Kłoczko

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

So you want to say that RH already guarantees Linux ABI compatibility below
glibc?

I don't think that's what I want to say. If I wanted to say that I'd
have said it.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@

[Nico Kadel-Garcia]

On Wed, Mar 15, 2017 at 9:51 AM, Tomasz Kłoczko

Post by Tomasz Kłoczko

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

So you want to say that RH already guarantees Linux ABI compatibility below
glibc? I would be really surprised if it would be truth .. and I'm 100% sure
that exactly this part is not in RH support small prints. In other words you
may have only impression that this part is already covered in support
conditions.
Again try to answer on question why long time ago other OSes abandoned
providing static libc?
Internally this part is and always will be affected by definition by any
future changes in kernel ABI. glibc it is not only libc library. Glibc
provides couple of other components which are using internal glibc ABI/API.
Shared libc wraps all those changes and allows handle (in long term) even
quite significant changes beneath own glibc public API/ABI and on boundary
between kernel<->user space without hurting user space binaries.
And one more clarification: remove static libraries from glibc distro
packages does not blocks static linking.
It will only removes possibility linking against static glibc libraries.

Yes. This is a blocker for some people, who want *completely* static
binaries to have complete binary control of their active package.
glibc changing from a random update and possibly introducing a
regression problem is anathema to some critical software developers,
and the compilation of completely static binaries has been helpful for
cross-platform compatibility, for building chroot cages, and for
building well managed containers of various sorts.

Been there, done that with sorting out the library dependencies for
rssh chroot cages some time ago.

Post by Tomasz Kłoczko
You can ignore me but you cannot ignore facts behind why something like libc
exist and why no one should use static version of the libc libraries.

I think you're mixing orthogonal concerns.

Post by Tomasz Kłoczko
Especially static linking with glibc is very dangerous as long if linked
binary is using NSS libc interface. Some people are thinking that "fully"
statically linked program does not use or will not need any DSOs. In case of
using by such binary NSS libc interface this not true as depends on NSS map
type and NSS settings (described in /etc/nsswitch.conf) will be causing
loading nss_<foo>.so DSOs.

Well, yes. nsswitch.conf has been a mess since it was invented, for
reasons beyond the scope of this discussion.

Post by Tomasz Kłoczko
Number of changes in glibc in internal NSS interface where quite big in
recent years, and if someone will/is using statically linked binary where
NSS interface is in use such binary will be loading NSS modules (probably)
compiled against not correct glibc.Result: execution of such binaries will
fail or even crash with SIGSEV.
https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F

You seem to pointing out that NSS is a stability problem. You're quite
right. Saying that "NSS is unstable, therefore glibc should be forced
to dynamic libraries only" does not follow. The underlying API for
nsswitch.conf and NSS does not change that quickly, it's the feature
churn for add-ons that are being tied into NSS. For high stability
software, *who cared*? You won't use the most recent NSS changes, and
if you do, they're quite likely to be available the the glibc static
library at the time you compile them. Statically.

Post by Tomasz Kłoczko
It is already known that within next few years NSS area in glibc it will be
probably one of the fastest changing area in glibc whole project. Solaris
already coverers in his own libc many NSS security related extensions. Glibc
has a lot to catch up here. All those upcoming changes will definitely even
harder kick back all people linking own executables against glibc static
libraries. This will be probably even bigger problem than all potential
kernel<->user space ABI changes.

You've a point about NSS instability. That's actually quite
frightening. I lack your confidence that it justifies enforcing
dynamic libraries, and it seems *very* unlikely that the API's will
change enough to break older, stable software.

Post by Tomasz Kłoczko
Other static libraries used by distribution are carrying as well real and
potential security risk.

It's true that it's a trade-off. The potential instability issue of a
glibc regression error is quite noticeable for high reliability
components, and even the "dnf update" process is vulnerable to glibc
update issues under some circumstances, such as running out of disk or
failing power during the update. High churn in the glibc library, such
as you're suggesting is likely for NSS, is a reason to *insist* on
retaining static libraries for glibc.

Post by Tomasz Kłoczko
Example: RH/Fedora is using bash which is linked against own copy of
readline (provided within bash original source tree). It was few CVEs in
readline in recent years and some people been exploiting fact that bash
was/is linked against readline with well known security issue.
So here is surprise: in case finding new 0-day bug(s) in readline it will be
necessary to provide not one readline fixed package but two .. readline and
bash.
Yes. RH/Fedora bash has some very well known security flaw which hanging
above whole distro reputation like a Damocles sword!!!
In last 20 years I've been trying to convince few people to remove exactly
this bash risk but last time when I've been trying this my English was not
good enough to express this enough clear and strong. Maybe this time ..

Good luck with that. Then please, raise it. I don't think you're going
to get anywhere with it. Bash is one of the components that *must* be
stable. A glibc update that introduces a problem could break the very
update processes used to update bash.

Post by Tomasz Kłoczko
Reality is that remove building and providing all of those +190 -static
packages will as well allow save a lot of CPU time on Fedora build systems.
I'm 100% sure that no one is using those static libraries and they are build
and packaged only because some project source trees default settings are
building those static libraries. That is only reason why those .a files are
still flying around!!!

Then go after them one at a time, not as a policy statement to be
imposed without the buy-in of those program owners.

Post by Tomasz Kłoczko
And yet another fact: in last decade number of packages providing static
copies of some libraries decreased few times (only in RH distribution). This
is because there are more tan few people aware that building packaging those
files is pointless.

Hardly. Many packagers of static environments do it by locking the yum
or dnf repository that they build software from, and use host images
rather than built up software enviroments to work with.

Post by Tomasz Kłoczko
Controlling internal entropy and keeping it on lowest possible level on
whole distro level should be everyone goal as well :)

And that's why people use static libraries. Because dynamically
udpated libraries which may have never been tested with your
individual, unique software combinations is *generating* entropy.

Post by Tomasz Kłoczko
Summarising. There are at least three reasons why static libraries should be
1) Constant ABI changes
2) Security risk
3) Waste of time/resources on building and providing static libraries

And reasons to keep them.

1) Complete software stability
2) Regession failures generated by buggy library updates
3) The difficulty of forcing restarts of all daemons which use the
updated libraries to incorporate the updates, rather than forcing an
update of the package itself with associated, schedulable daemon
restarts.

Post by Tomasz Kłoczko
kloczek
--
Tomasz Kłoczko | : http://lnkd.in/FXPWxH
_______________________________________________

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to d

[Tomasz Kłoczko]

On 16 March 2017 at 04:50, Nico Kadel-Garcia <***@gmail.com> wrote:
[..]

Post by Nico Kadel-Garcia

Post by Tomasz Kłoczko
And one more clarification: remove static libraries from glibc distro
packages does not blocks static linking.
It will only removes possibility linking against static glibc libraries.

Yes. This is a blocker for some people, who want *completely* static
binaries to have complete binary control of their active package.
glibc changing from a random update and possibly introducing a
regression problem is anathema to some critical software developers,
and the compilation of completely static binaries has been helpful for
cross-platform compatibility, for building chroot cages, and for
building well managed containers of various sorts.

There are few typical scenarios when someone may want to have 100% static
binaries:
1) to have binary independent from ABI changes on distribution level in any
used shared libraries.

So here is kind contradiction because my past experience that such binaries
are used so long (+6 years) that it causes silent issues with conflicts on
kernel<->user space and sooner or later initial intention turns into
disaster as no one remembers who and how initially such binary was made.

2) some bootstrapping scenarios like for example static linking grub
binaries

In such cases binaries are will be regenerated with every small change in
non-public ABI/API changes will be followed by immediate recompilation of
such binaries so ris here is effective null and such limited number
binaries should be accepted and carefully maintained.
Scenario when such special binaries been crafted for initrd already are
nullified because today even smallest systems have enough memory to use
regular shared libraries. Simple one one needs today to fit such initrds on
3.5' floppy disk with 1.44MB available storage.

3) some people are thinking that static linking make sense from performance
or resource consumption perspective.

Here is the issue that such binaries would be typically moved/propagated
around to different location executed in multiple instances. What was
initial intention of saving memory typically turns into higher memory
consumption. As long as such binaries will be detached from original
locations installed by regular locations risk that those binaries will be
used longer to expose them to risk created by kernel<->user space ABI
changes and internal glibc is relatively high.

[..]

Post by Nico Kadel-Garcia

Post by Tomasz Kłoczko
Number of changes in glibc in internal NSS interface where quite big in

recent years, and if someone will/is using statically linked binary where

Post by Tomasz Kłoczko
NSS interface is in use such binary will be loading NSS modules

(probably)

Post by Tomasz Kłoczko
compiled against not correct glibc.Result: execution of such binaries

will

Post by Tomasz Kłoczko
fail or even crash with SIGSEV.
https://sourceware.org/glibc/wiki/FAQ#Even_statically_

linked_programs_need_some_shared_libraries_which_is_not_
acceptable_for_me.__What_can_I_do.3F
You seem to pointing out that NSS is a stability problem. You're quite
right. Saying that "NSS is unstable, therefore glibc should be forced
to dynamic libraries only" does not follow. The underlying API for
nsswitch.conf and NSS does not change that quickly, it's the feature
churn for add-ons that are being tied into NSS. For high stability
software, *who cared*? You won't use the most recent NSS changes, and
if you do, they're quite likely to be available the the glibc static
library at the time you compile them. Statically.

You are wrong that this is abut messiness/stability of the NSS interface.
We are talking about *internal glibc ABI/API* on which *none of the
system/distribution binaries should rely on such internal interfaces which
any project maintainer has freedom to change without even noticing this in
changelogs*.

Using statically linked binaries creates RISK here if those binaries will
be not refreshed.
As long as number of such binaries will be limited and will be under
regular distro hood control I have no problems with such binaries.
As long as whole distribution consumer may start using such internal ABI
interface we are entering on area where sooner or later initial honest
intention will turn against someone who had such intention.
Here is really end of the story if you will really accept meaning,
consequences and existence of internal libraries APIs/ABIs. This is why
executable binaries have public symbols tables. NSS is not part of the
public interface.

Risk of not to be exposed on internal NSS ABI changes can be very easy
nullified by using in such rare cases static linking with libc like uClibc
which has no NSS interface.

Post by Nico Kadel-Garcia

Post by Tomasz Kłoczko
Example: RH/Fedora is using bash which is linked against own copy of
readline (provided within bash original source tree). It was few CVEs in
readline in recent years and some people been exploiting fact that bash
was/is linked against readline with well known security issue.
So here is surprise: in case finding new 0-day bug(s) in readline it

will be

Post by Tomasz Kłoczko
necessary to provide not one readline fixed package but two .. readline

and

Post by Tomasz Kłoczko
bash.
Yes. RH/Fedora bash has some very well known security flaw which hanging
above whole distro reputation like a Damocles sword!!!
In last 20 years I've been trying to convince few people to remove

exactly

Post by Tomasz Kłoczko
this bash risk but last time when I've been trying this my English was

not

Post by Tomasz Kłoczko
good enough to express this enough clear and strong. Maybe this time ..

Good luck with that. Then please, raise it. I don't think you're going
to get anywhere with it. Bash is one of the components that *must* be
stable. A glibc update that introduces a problem could break the very
update processes used to update bash.

Just try to check *BSDs, Solaris and even few other Linux distros how it is
with readline linking before raising this that it is about stability of
something.

BTW: this subject has a bit bigger context as bash provides /bin/sh in
Fedora.
Problem is that other OSes are a bit more strict about using non-SH syntax
when "#!/bin/sh" is used in scrip preamble. Occasionally it causes some
confusion when such script written on Linux will be moved to other OS
platform and suddenly it stop correctly working.
/bin/sh is one of the core parts of the OS binaries. Dependencies here
should be as short as it is really only possible.
All those problems is possible to solve in few months (I've done it one
time on scale whole Linux distribution) by changing /bin/sh to real SH like
ksh93 or pdksh (today ksh is better candidate).
A lot of work could to be done before final switch but it will produce
system base image without risks which are come with bash as /bin/sh
provider.

In last decade bash already created enough number CVEs to start thinking
about moving away from bash as /bin/sh provider.
Sun/Oracle already done careful ksh security review which bash never had
done. Because ksh is very small and his main goal is provide /bin/sh number
of any future changes will be very well known and limited to cleanups and
bug fixes.
Changing /bin/sh to real SH interpreter IMO should be kind of long term
Fedora target. It will be not easy and maybe even painful but minimize
/bin/sh dependencies and minimize security risk is IMO worth to start
thinking about some preparations to be opened on such change in the future.
Other issue is that bash is not the fastest /bin/sh interpreter :)

Nevertheless I don't want to discuss this subject now. This should be
discussed separately.
If someone want to continue please extract above and change subject.

[..]

Post by Nico Kadel-Garcia

Post by Tomasz Kłoczko
Summarising. There are at least three reasons why static libraries

should be

Post by Tomasz Kłoczko
1) Constant ABI changes
2) Security risk
3) Waste of time/resources on building and providing static libraries

And reasons to keep them.
1) Complete software stability
2) Regession failures generated by buggy library updates
3) The difficulty of forcing restarts of all daemons which use the
updated libraries to incorporate the updates, rather than forcing an
update of the package itself with associated, schedulable daemon
restarts.

Again: minimize /bin/sh dependencies. Minimize number of other
dependencies. Here are laying *biggest* deposits of minimize such risks
(waaay bigger than those related to static linking).
Small example.
Long time ago I've been able to gain minimize number of dependencies by
injecting LDFLAGS="-Wl,--as-needed" into %configure macros. As on mean time
cmake emerged this move will be not so effective as it was decade ago.
Today I think that better solution could apply small change in ld default
behavior to use by default ---as-need (and make -fno-as-needed optional).
This could be done in one few lines patch (few lines .. because it would be
good IMO add printing warning that linking with some libraries was
dropped). Result would be reduction whole distribution rpm REQUIRES entries
by at least 10-20%.
For example Fedora rawhide still is in the middle openssl migration to
1.1.x. If before this migration all packages would be linked with
--as-need it will be necessary to rebuild much less packages.
Printing by ld warnings may allow fix original build code by remove
redundant -l<foo> in those frameworks implementations.
Few weeks ago I've done short experiment with injecting
LDFLAGS="-Wl,--as-need" into %configure parameters of the gnome-shell.spec.
After producing two binary packages with and without -Wl,--as-need here is
the diff of the output of the queries:

$ rpm -qp --qf "[%{REQUIRENAME} %{REQUIREFLAGS:depflags}
%{REQUIREVERSION}\n]" gnome-shell-3.2*.fc26.x86_64.rpm

--- gnome-shell.cur 2016-09-18 12:51:51.496412774 +0100
+++ gnome-shell.new 2016-09-19 20:16:59.613362311 +0100
@@ -62,10 +62,6 @@
libgthread-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libical.so.2()(64bit)
-libicalss.so.2()(64bit)
-libicalvcal.so.2()(64bit)
-libicui18n.so.57()(64bit)
-libicuuc.so.57()(64bit)
libinput.so.10()(64bit)
libjson-glib-1.0.so.0()(64bit)
libm.so.6()(64bit)
@@ -96,7 +92,6 @@
libsecret-1.so.0()(64bit)
libsoup-2.4.so.1()(64bit)
libstartup-notification-1.so.0()(64bit)
-libstdc++.so.6()(64bit)
libsystemd.so.0()(64bit)
libsystemd.so.0(LIBSYSTEMD_209)(64bit)
libtelepathy-glib.so.0()(64bit)
@@ -114,12 +109,10 @@


As you see only this package is not using libstdc++ and in case of any ABI
changes in libstdc++ library force rebuild of this package will be not
necessary.
In this exact case libical SONAME dependencies have been reduced so ld.so
will be not allocating and initializing jump tables between some binaries
and ical libraries.
Remove libstdc++ dependency has been done by jet another not widely known
trick that gcc can be used to compile C++ code as long as it is relatively
simple code. So in this case %configure parameters has been changes to add:

%configure \
+ CXX="%{__cc}" \
+ CXXFLAGS="%{optflags} -fno-rtti -fno-exceptions" \
+ LDFLAGS="-Wl,--as-needed" \

In some extreme cases using -fno-exceptions can *reduce size of the
generated code by up to 30%* and such code will be no longer using
libstdc++.
Such compile time modification may be a bit risk in case using it to
compile libraries (as produced libraries will be not possible to handle
exceptions across C++ object inheritance trees but some projects like KDE
have strict policy about not use and not provide exceptions support as to
heavy technique (on code size) so they are already in original build
framework deliberately injecting -fno-exceptions, however in case regular
executable program binaries this trick brings only good things.

Back to linker optimisations.
I know that in some extreme packages cases using linker with --as-need *can
halven* number of SONAME package dependencies.

In other words all those goals which you mention are not strictly related
to static linking and it is possible to do a lot (or much more) to minimize
such risks without even thinking about provide glibc-static. Static linking
with glibc touches at the moment only few packages. Reduction of SONAME
dependencies will be related probably to ~3/4 of all Fedora packages so we
are talking about ~15k packages.
Do you see how few lines change cay change few magnitude orders more? (if
you are really care about regression problems/risks coming from
dependencies).

Spreading ld with a bit different behavior printing warnings about overuse
some -l<foo> in longer consequences will not only improve Fedora binaries
health but as long as source code maintainers of the packages used by
Fedora will start use changed ld they will see that they can improve linker
settings of own projects.
Such subjects should be consulted with binutils maintainers because they
would able to asses risk of doing such change.
As long as I've done many times full recompilation on the scale of whole
distribution in the past I know that sometimes is necessary to add small
linker fix when library X is linked with other libraries A and B and only A
is used and linked executable is using libX and libB ABI but has no -lB in
linker options, but majority of those changes have been already merged to
most of the packages source trees.

kloczek

[Kevin Kofler]

Post by Tomasz Kłoczko
Long time ago I've been able to gain minimize number of dependencies by
injecting LDFLAGS="-Wl,--as-needed" into %configure macros. As on mean
time cmake emerged this move will be not so effective as it was decade
ago. Today I think that better solution could apply small change in ld
default behavior to use by default ---as-need (and make -fno-as-needed
optional). This could be done in one few lines patch (few lines .. because
it would be good IMO add printing warning that linking with some libraries
was dropped). Result would be reduction whole distribution rpm REQUIRES
entries by at least 10-20%.

FYI, this is what Mandriva (back then), now Mageia and OpenMandriva, have
been doing for years (and still do).

https://wiki.mageia.org/en/Overlinking_issues_in_packaging

Post by Tomasz Kłoczko
As long as I've done many times full recompilation on the scale of whole
distribution in the past I know that sometimes is necessary to add small
linker fix when library X is linked with other libraries A and B and only
A is used and linked executable is using libX and libB ABI but has no -lB
in linker options, but majority of those changes have been already merged
to most of the packages source trees.

Indeed, the folks involved in the Mandriva --as-needed migration reported
that the effort required was similar to the one for the "no more transitive
linking" change
https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking
in Fedora (since Fedora 13) that you are alluding to.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorapro

[Nico Kadel-Garcia]

On Thu, Mar 16, 2017 at 6:58 AM, Tomasz Kłoczko

Post by Tomasz Kłoczko
[..]

Post by Nico Kadel-Garcia

Post by Tomasz Kłoczko
And one more clarification: remove static libraries from glibc distro
packages does not blocks static linking.
It will only removes possibility linking against static glibc libraries.

Yes. This is a blocker for some people, who want *completely* static
binaries to have complete binary control of their active package.
glibc changing from a random update and possibly introducing a
regression problem is anathema to some critical software developers,
and the compilation of completely static binaries has been helpful for
cross-platform compatibility, for building chroot cages, and for
building well managed containers of various sorts.

There are few typical scenarios when someone may want to have 100% static
1) to have binary independent from ABI changes on distribution level in any
used shared libraries.

And regression errors not present in the version of the library they
built and tested the software with. This is a *very big deal*. Been
there, done that, got the T-shirt. Having provenance for your
software, and certainty that library updates will not affect anything
but the expected software is critical. Not protecting critical,
high-availability from software patches or updates to the rest of the
operating system isa very, very big deal for some of us.

Post by Tomasz Kłoczko
So here is kind contradiction because my past experience that such binaries
are used so long (+6 years) that it causes silent issues with conflicts on
kernel<->user space and sooner or later initial intention turns into
disaster as no one remembers who and how initially such binary was made.

That is also a problem. It's also not really solved by dynamic
libraries. if the ABI for the libraries is changing that much, it's
likely necessary to recompile the base software *anyway*.

Post by Tomasz Kłoczko
2) some bootstrapping scenarios like for example static linking grub
binaries
In such cases binaries are will be regenerated with every small change in
non-public ABI/API changes will be followed by immediate recompilation of
such binaries so ris here is effective null and such limited number binaries
should be accepted and carefully maintained.

And... we're to build them without glibc-static.... how?

Post by Tomasz Kłoczko
Scenario when such special binaries been crafted for initrd already are
nullified because today even smallest systems have enough memory to use
regular shared libraries. Simple one one needs today to fit such initrds on
3.5' floppy disk with 1.44MB available storage.

Boot media are one of those cases where binary stability are *most* critical.

Post by Tomasz Kłoczko
3) some people are thinking that static linking make sense from performance
or resource consumption perspective.
Here is the issue that such binaries would be typically moved/propagated
around to different location executed in multiple instances. What was
initial intention of saving memory typically turns into higher memory
consumption. As long as such binaries will be detached from original
locations installed by regular locations risk that those binaries will be
used longer to expose them to risk created by kernel<->user space ABI
changes and internal glibc is relatively high.

Straw man argument, 5 yard penalty.

The relocation of binaries to different places in the same operating
system is not the problem. Moving it from one operating sytem or
container to another, *that* is the problem. And running exactly the
version you expect, even if it's inside a heavily modified container
or distinct operating system of some sort is a powerful goal. I don't
run into it as much as I used to, but I certainly used to have to
compile components statically in various environments for use
elsewhere.

Post by Tomasz Kłoczko

Post by Nico Kadel-Garcia
You seem to pointing out that NSS is a stability problem. You're quite
right. Saying that "NSS is unstable, therefore glibc should be forced
to dynamic libraries only" does not follow. The underlying API for
nsswitch.conf and NSS does not change that quickly, it's the feature
churn for add-ons that are being tied into NSS. For high stability
software, *who cared*? You won't use the most recent NSS changes, and
if you do, they're quite likely to be available the the glibc static
library at the time you compile them. Statically.

You are wrong that this is abut messiness/stability of the NSS interface.
We are talking about internal glibc ABI/API on which none of the
system/distribution binaries should rely on such internal interfaces which
any project maintainer has freedom to change without even noticing this in
changelogs.

If they're dinking with it that much, it's likely to lead to changes
in the ABI as well and force recompilation. That level of change is
not normally permitted within a single Fedora release, and packages
for Fedora are rebuilt for new releases.

Again, straw man argument, and another 5 yeard penalty.

Post by Tomasz Kłoczko
Using statically linked binaries creates RISK here if those binaries will be
not refreshed.

Now, *that* is real. However, see above, to wit:

* Packages for Fedora are rebuilt for new releases.

If you install a package from a previous Fedora release, or run it on
your newer Fedora release, well, you have a risk of trouble. Mind you,
I've *done* so when build environments for older software didn't work
for new releases. It's more common with highly proprietary software
whose authors tended to "tune" their performance at the cost of
portability.

Post by Tomasz Kłoczko
As long as number of such binaries will be limited and will be under regular
distro hood control I have no problems with such binaries.
As long as whole distribution consumer may start using such internal ABI
interface we are entering on area where sooner or later initial honest
intention will turn against someone who had such intention.
Here is really end of the story if you will really accept meaning,
consequences and existence of internal libraries APIs/ABIs. This is why
executable binaries have public symbols tables. NSS is not part of the
public interface.
Risk of not to be exposed on internal NSS ABI changes can be very easy
nullified by using in such rare cases static linking with libc like uClibc
which has no NSS interface.

And if I walk on only my right foot, I can save wear and tear on my
left shoe. Doesn't seem worth the effort. uClibc is a cool idea, but
unlikely to work well for a broad variety of complex software which
has ever been compiled or tested with it.

Post by Tomasz Kłoczko
In last decade bash already created enough number CVEs to start thinking
about moving away from bash as /bin/sh provider.
Sun/Oracle already done careful ksh security review which bash never had
done. Because ksh is very small and his main goal is provide /bin/sh number
of any future changes will be very well known and limited to cleanups and
bug fixes.

And we can get C++ programmers to going back to C, to avoid the
function overloading problem.

I'm afraid it's not gonna happen.

Post by Tomasz Kłoczko
Changing /bin/sh to real SH interpreter IMO should be kind of long term
Fedora target. It will be not easy and maybe even painful but minimize
/bin/sh dependencies and minimize security risk is IMO worth to start
thinking about some preparations to be opened on such change in the future.
Other issue is that bash is not the fastest /bin/sh interpreter :)

It's a lot of work with a profound loss of shell functionality and
features, with a nebulous security benefit. Sorry, but I don't see it
happening anytime in the foreseeable future.

Post by Tomasz Kłoczko
Again: minimize /bin/sh dependencies. Minimize number of other dependencies.
Here are laying biggest deposits of minimize such risks (waaay bigger than
those related to static linking).
Small example.
Long time ago I've been able to gain minimize number of dependencies by
injecting LDFLAGS="-Wl,--as-needed" into %configure macros. As on mean time
cmake emerged this move will be not so effective as it was decade ago. Today
I think that better solution could apply small change in ld default behavior
to use by default ---as-need (and make -fno-as-needed optional).
This could be done in one few lines patch (few lines .. because it would be
good IMO add printing warning that linking with some libraries was dropped).
Result would be reduction whole distribution rpm REQUIRES entries by at
least 10-20%.

Now, *THAT* is an interesting point. I like it. Want to toss in a
feature request for it?

Post by Tomasz Kłoczko
For example Fedora rawhide still is in the middle openssl migration to
1.1.x. If before this migration all packages would be linked with --as-need
it will be necessary to rebuild much less packages.
Printing by ld warnings may allow fix original build code by remove
redundant -l<foo> in those frameworks implementations.
Few weeks ago I've done short experiment with injecting
LDFLAGS="-Wl,--as-need" into %configure parameters of the gnome-shell.spec.
After producing two binary packages with and without -Wl,--as-need here is
$ rpm -qp --qf "[%{REQUIRENAME} %{REQUIREFLAGS:depflags}
%{REQUIREVERSION}\n]" gnome-shell-3.2*.fc26.x86_64.rpm
--- gnome-shell.cur 2016-09-18 12:51:51.496412774 +0100
+++ gnome-shell.new 2016-09-19 20:16:59.613362311 +0100
@@ -62,10 +62,6 @@
libgthread-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libical.so.2()(64bit)
-libicalss.so.2()(64bit)
-libicalvcal.so.2()(64bit)
-libicui18n.so.57()(64bit)
-libicuuc.so.57()(64bit)

Ye gods, yes, this kind of dependency improvement is invaluable.

Post by Tomasz Kłoczko
libinput.so.10()(64bit)
libjson-glib-1.0.so.0()(64bit)
libm.so.6()(64bit)
@@ -96,7 +92,6 @@
libsecret-1.so.0()(64bit)
libsoup-2.4.so.1()(64bit)
libstartup-notification-1.so.0()(64bit)
-libstdc++.so.6()(64bit)

That it includes libstdc++ is fascinating.

Post by Tomasz Kłoczko
Back to linker optimisations.
I know that in some extreme packages cases using linker with --as-need can
halven number of SONAME package dependencies.

I *like* it!!!

Post by Tomasz Kłoczko
In other words all those goals which you mention are not strictly related to
static linking and it is possible to do a lot (or much more) to minimize
such risks without even thinking about provide glibc-static. Static linking

Umm. No. You're mistaking "reduction of library dependencies" with
"discaarding static library compilation".

Post by Tomasz Kłoczko
with glibc touches at the moment only few packages. Reduction of SONAME
dependencies will be related probably to ~3/4 of all Fedora packages so we
are talking about ~15k packages.
Do you see how few lines change cay change few magnitude orders more? (if
you are really care about regression problems/risks coming from
dependencies).

As I said, i *like* this.

Post by Tomasz Kłoczko
Spreading ld with a bit different behavior printing warnings about overuse
some -l<foo> in longer consequences will not only improve Fedora binaries
health but as long as source code maintainers of the packages used by Fedora
will start use changed ld they will see that they can improve linker
settings of own projects.
Such subjects should be consulted with binutils maintainers because they
would able to asses risk of doing such change.
As long as I've done many times full recompilation on the scale of whole
distribution in the past I know that sometimes is necessary to add small
linker fix when library X is linked with other libraries A and B and only A
is used and linked executable is using libX and libB ABI but has no -lB in
linker options, but majority of those changes have been already merged to
most of the packages source trees.

*Cool*. And you've my sympathies, those kinds of subtle undetected
dependencies can be tricky to resolve.

Post by Tomasz Kłoczko
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai

[Tomasz Kłoczko]

On 18 March 2017 at 06:21, Nico Kadel-Garcia <***@gmail.com> wrote:
[..]

Post by Richard W.M. Jones

Post by Tomasz Kłoczko
So here is kind contradiction because my past experience that such

binaries

Post by Tomasz Kłoczko
are used so long (+6 years) that it causes silent issues with conflicts

on

Post by Tomasz Kłoczko
kernel<->user space and sooner or later initial intention turns into
disaster as no one remembers who and how initially such binary was made.

That is also a problem. It's also not really solved by dynamic
libraries. if the ABI for the libraries is changing that much, it's
likely necessary to recompile the base software *anyway*.

As long as binary X is using libc and libc is hiding all kernel<->user ABI
changes dynamic linking solves ALL ISSUES here.
Look on Solaris. This is "walking proof" that such approach solves those
issues.
All what is necessary is strict control of what happens on ABI layer which
in recent years at least comes to top of priorities critical Linux
developers.
Many of those people in recent years changed his mid to be "true believers
of ABI stability" like it happened on Solaris on other grown Unices :)

Post by Richard W.M. Jones

Post by Tomasz Kłoczko
2) some bootstrapping scenarios like for example static linking grub
binaries
In such cases binaries are will be regenerated with every small change in
non-public ABI/API changes will be followed by immediate recompilation of
such binaries so ris here is effective null and such limited number

binaries

Post by Tomasz Kłoczko
should be accepted and carefully maintained.

And... we're to build them without glibc-static.... how?

uClibc is the answer :)
There is no any reasons why for these few critical binaries uClibc cannot
be used :)
Better .. many Linux distributions entered on this path many years ago so
it is practical proof which is possible to touch and smell that
glibc-static is only way of generate those binaries.

Post by Richard W.M. Jones
Scenario when such special binaries been crafted for initrd already are

Post by Tomasz Kłoczko
nullified because today even smallest systems have enough memory to use
regular shared libraries. Simple one one needs today to fit such initrds

on

Post by Tomasz Kłoczko
3.5' floppy disk with 1.44MB available storage.

Boot media are one of those cases where binary stability are *most* critical.

Try to observe what other distros are doing. At the moment they are packing
in initrd ALL possible to load kernel module.
As long as HW has +256MB RAM you can almost all this RAM for initrd. At the
end of initrd everything will be released.
In other words: still maintaining special way to craft some binaries for
initr is pure waste of time in context of Fedora as Fedora never was and
withing next +3-4 still will be not true embedded system platform. It will
be at the time when nail size computers will have +256-512MB RAM.
Even today HW like VoCore2 (http://vocore.it/ has only 128MB RAM)
I have 5 these small cubes at home and they are perfect for home systems
engineer like me :D
3 weeks ago I've started working on organize on such HW full install server
for all my Linuxes and Solarises which I have at home and I must say I have
reall fun plaing this HW :)
Look on
https://kloczek.wordpress.com/2017/03/08/vocore2-serial-console-equipment/ how
really small it is :)
I have now fully working PXE (DNS, DHCP, TFTP, HTTP) server for Linuxes and
yesterday I've started on putting on the same cube all Solaris AI server
(Automated Installer) stuff. As long as AI is using only protocols it is
possible to use Linux to install remotely Solaris.
When I'll finish this will try to write full step-by-step instruction how
to do this.
Such HW is not speed monster but it is perfect to put it gassy box with
label "in case emergency situation break the glass".
Many years ago RealAdmin(tm) had in the pocket rescue 3.5' disk. After this
it was replaced by CDs/DVDs to replaced by USB stick but now in pocket you
can hold "Swiss army knife" with which you can rescue at the same time few
computers in DC after plugging it into the network and rescue box over PXE
in booted rescue mode :D

Going back to the static glibc subject .. by natural reasons point about
bootstrap/initrd static binaries sooner or later will gone from static libc
dependencies.
IIRC Solaris in own initrd (miniroot) is using only dynamic binaries copied
from regular system.
Sooner or later the same will be with all full Linux distros.
Crafting those static binaries is more and more pointless with growing size
of the RAM even in smallests systems HWs reachable by distribution like
Fedora.

Post by Richard W.M. Jones
3) some people are thinking that static linking make sense from performance

Post by Tomasz Kłoczko
or resource consumption perspective.

[..]

Post by Richard W.M. Jones
Straw man argument, 5 yard penalty.
The relocation of binaries to different places in the same operating
system is not the problem. Moving it from one operating sytem or
container to another, *that* is the problem. And running exactly the
version you expect, even if it's inside a heavily modified container
or distinct operating system of some sort is a powerful goal. I don't
run into it as much as I used to, but I certainly used to have to
compile components statically in various environments for use
elsewhere.

I'm betting that sooner or later even here static libraries will be
abandoned.
Why? because with growing number of CPU cores in such systems still *CPU
caches is the biggest bottleneck.*
Simple such cache is not made out of rubber.
In nearest future it is easy to imagine that virtualization platform would
be running not tenths like it is usually today but thousands instances
maximum sharing memory pages between instances
VMs/partitions/zone/containers will be more and more critical from CPU
cache perspective.
Only solution of those type challenges will be using maximum sharing
resources between those mimi-systems .. with full sharing on DSO layer as
well.
People today working on dockers and other containerization pinning up those
thing t statically linked binaries are shooting in own foot making those
platform prone on not sharing as much as it is only possible.
No .. by DEFINITION here as well should be used regular distro binaries. If
not those containers ships will start sinking after collisions with CPU
caches icebergs.
In future eben VM based containerisation as may relly beneath on
deduplication may start share some physical memory pages mapped to
different VMs minimizing CPU caches misses.
More than ten years ago on one of fist version Solaris 10 as POC/test have
been done experiment with running few thousands of zones.
IIRC it was done on using UltraSparch 10 workstation. Today laptops are
more powerful than this old HW.
You will be really surprised how much Solaris non-global zones is possible
to pack into single T5 HW with 256-512 CPUs visible in global zone.
Cloning system volumes on ZFS layer allow to share very easy physical
memory pages between all those zone if they are not running some branded
zones (solution how to run old binaries even Solaris 7 or 8 on top of
latest Solaris 11.3 kernel).
People without such experience really are doing more harm than good for
Linux by using static binaries :( .. and it will be obvious withing next
few years.

Post by Richard W.M. Jones

Post by Tomasz Kłoczko

Post by Nico Kadel-Garcia
You seem to pointing out that NSS is a stability problem. You're quite
right. Saying that "NSS is unstable, therefore glibc should be forced
to dynamic libraries only" does not follow. The underlying API for
nsswitch.conf and NSS does not change that quickly, it's the feature
churn for add-ons that are being tied into NSS. For high stability
software, *who cared*? You won't use the most recent NSS changes, and
if you do, they're quite likely to be available the the glibc static
library at the time you compile them. Statically.

You are wrong that this is abut messiness/stability of the NSS interface.
We are talking about internal glibc ABI/API on which none of the
system/distribution binaries should rely on such internal interfaces

which

Post by Tomasz Kłoczko
any project maintainer has freedom to change without even noticing this

in

Post by Tomasz Kłoczko
changelogs.

If they're dinking with it that much, it's likely to lead to changes
in the ABI as well and force recompilation. That level of change is
not normally permitted within a single Fedora release, and packages
for Fedora are rebuilt for new releases.
Again, straw man argument, and another 5 yeard penalty.

As I said already. To the glibc NSS subsystem are coming now waves of
necessary extension.
Sorry to say this again but with every day probability that we will reach
some new NSS step will cause issue which last time happened +12 years ago.
Now really is best time to prepare to abandon this ship and enter on try
land to not be affected by coming next tsunami.
You may be happy that you will have 5 yards more on this sunny beach ..
because nothing bad happened in last 10 years but .. sea uncovering beach
is only a pre symptom coming tsunami :)
Remember one of the Murphy's law: "if something may happen it will happen"
.. or old engineering joke about automated announcement prerecorded to
played in emergency situation on airport "Everything is under control.
Nothing can go wrong (hrr) .. can go wrong (hrr) .. can go wrong (hrr) ..
can go wrong .." :)

Post by Richard W.M. Jones
Using statically linked binaries creates RISK here if those binaries will be

Post by Tomasz Kłoczko
not refreshed.

* Packages for Fedora are rebuilt for new releases.

At the moment such risk is nullified by quite regular full scale Fedora as
distro mass rebuilds.
Nevertheless this part was not about binaries coming with distro but
binaries generated by distro consumers (mostly sys admins).

[..]

Post by Richard W.M. Jones

Post by Tomasz Kłoczko
Risk of not to be exposed on internal NSS ABI changes can be very easy
nullified by using in such rare cases static linking with libc like

uClibc

Post by Tomasz Kłoczko
which has no NSS interface.

And if I walk on only my right foot, I can save wear and tear on my
left shoe. Doesn't seem worth the effort. uClibc is a cool idea, but
unlikely to work well for a broad variety of complex software which
has ever been compiled or tested with it.

Using uClibc it is not an idea. It is *solution* of some well known glic
issues.
You may like or hate glibc but as same as libcs from other Unices already
maaany years ago hit NSS issue as well they decided to stop provide libc.a
generated from regular full scale system libc.
Look on OpenIdiana source tree and you will find that Sun many years ago
separated and started maintaining these binaries separately as kind of
exception which simple was not possible to solve using libc.a generated out
of regular source code of regular OS libc.
Simple such libc is to complex to use it in such cases.
As well risk of maintaining such low level exceptional code in future by
some big-OS-changes is almost null as those changes very rarely are
touching bootstrap.
In case of Solaris last time it happened when this OS started moving from
UFS to ZFS with BEs (Boot Environment) created on top cloned rootfs it
started touching early boot stage procedure and it was necessary to change
couple of thing here.
If Linux will decide to fully commit similar way on top of btrfs because
some Solaris adaptations have been already done and committed to Grub2
probability that it will be necessary to do something to prepare Linux for
such scenario will be almost zero because it will be probably possible
share Solaris/ZFS code or number of such adaptations will be
AlmostNothing(tm).
Today playing with latest uboot on my pine64 just found that even uboot has
merged zfs support (which is jaw dropping ..)
I don't thing that it will happen in next 5 years because btrfs in such
context is in quite embryonal stage.

Post by Richard W.M. Jones
In last decade bash already created enough number CVEs to start thinking

Post by Tomasz Kłoczko
about moving away from bash as /bin/sh provider.
Sun/Oracle already done careful ksh security review which bash never had
done. Because ksh is very small and his main goal is provide /bin/sh

number

Post by Tomasz Kłoczko
of any future changes will be very well known and limited to cleanups and
bug fixes.

And we can get C++ programmers to going back to C, to avoid the
function overloading problem.
I'm afraid it's not gonna happen

I think that you totally lost my point here.
I have o idea how it is possible pin up your C/C++ analogy to security risk
context.
Please try to read above one more time. I'm sure that you can understand
above ..

Post by Richard W.M. Jones
Changing /bin/sh to real SH interpreter IMO should be kind of long term

Post by Tomasz Kłoczko
Fedora target. It will be not easy and maybe even painful but minimize
/bin/sh dependencies and minimize security risk is IMO worth to start
thinking about some preparations to be opened on such change in the

future.

Post by Tomasz Kłoczko
Other issue is that bash is not the fastest /bin/sh interpreter :)

It's a lot of work with a profound loss of shell functionality and
features, with a nebulous security benefit. Sorry, but I don't see it
happening anytime in the foreseeable future.

Not to much .. really. Trust me I've walked all this path in only few
months doing more than 50/60% of whole work doing many things in parallel.
Here is just your impression how it complicated it is against what I've
personally done.
As result of this work most results of necessary fixes already landed in
source trees of many OSS projects so partially some work already has been
done.

First as pre step you should only take care of using #!/bin/sh instead
#!bin/bash. Most (+95%) of the scripts are overusing bash in script
preamble.
Will try to open thread with this soon,
Such work can be perfectly scaled on many Fedora developers even with low
skills giving them something "real to fix" opportunity :)
"Build it and they will come .. " :)

Fedora *Debashfication* Project may as well raise generally Linux community
awareness about difference between Bash and Posix SH as scripts
interpreters that here relation is like between squares and rectangles.
Long term effects will be only positive ..

Even if now complexity level is for Fedora relatively big opening such
project as low priority thing would be very fruitful.
Start discussion about this ASAP does not mean "move Fedora /bin/sh to
Posix SH in next few months".
No. Decision about final push can be made at any time as consequence of
conclusion that "we can remove this stain because presoaking has been done
enough long .. so now we can put everything in washing machine" :)

[..]

Post by Richard W.M. Jones

Post by Tomasz Kłoczko
In other words all those goals which you mention are not strictly

related to
static linking and it is possible to do a lot (or much more) to minimize

Post by Tomasz Kłoczko
such risks without even thinking about provide glibc-static. Static

linking
Umm. No. You're mistaking "reduction of library dependencies" with
"discaarding static library compilation".

You been a bit ticked my distraction in whole discussion that linker
optimization has something to do with static linking in a some straight way
:)
No .. these are completely two parallel/independent subjects which have one
common part in its roots about lowering risks, lowering number of issues
catched by regression tests and keeping distro layer entropy on
healthy/lowest possible level. Nothing more and only this ..

[..]

Post by Richard W.M. Jones
*Cool*. And you've my sympathies, those kinds of subtle undetected
dependencies can be tricky to resolve.

Thx for +1 about linker optimisations :)
However I think that we need more voices/votes to push first pebble on this
slope .. anyone else?

kloczek

[Josh Stone]

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

Even if Fedora removed it, we could still make the business decision to
add it back to RHEL.

Post by Jonathan Wakely
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

This may still be a useful consideration for Fedora itself. Would we
alienate anyone if Fedora removed glibc-static?
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-

[Zygmunt Krynicki]

Post by Josh Stone
This may still be a useful consideration for Fedora itself. Would we
alienate anyone if Fedora removed glibc-static?

I think that this particular case should not be removed. Some tools do need static linking (e.g. initrd bits) and while those are obscure they are not really gone or on their way out. I would prefer not to remove static libraries even if they cause the well known issues as people that use them typically know why they are doing it.

Best regards
ZK
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscri

[Daniel P. Berrange]

Post by Josh Stone

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

Even if Fedora removed it, we could still make the business decision to
add it back to RHEL.

Post by Jonathan Wakely
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

This may still be a useful consideration for Fedora itself. Would we
alienate anyone if Fedora removed glibc-static?

Yes, you would prevent us from being able to build static binaries for
the QEMU system emulators in Fedora QEMU packages. This in turn prevents
them from being used to provide seemless execution from non-native
architecture chroots / containers. This is used for example, by flatpack
to allow non-native architecture compilation, or as well as by myself
for various personal projects needing non-native compilation environments.

I agree there are many reasons why static libraries are a bad idea in
general, particularly the security implications, but they are none the
less useful at times and not every usage scenario has the same security
requirements.

NB, throwing out all the -static RPMs doesn't magically remove static
compilation from Fedora. There are entire non-C language toolchains in
Fedora that are based on static compilation - eg OCaml and Go

Regards,
Daniel

[Josh Stone]

Post by Daniel P. Berrange

Post by Josh Stone

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

Even if Fedora removed it, we could still make the business decision to
add it back to RHEL.

To be clear, I'm not advocating removal, just trying to say that
worrying about RHEL is the wrong approach.

Post by Daniel P. Berrange

Post by Josh Stone

Post by Jonathan Wakely
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

This may still be a useful consideration for Fedora itself. Would we
alienate anyone if Fedora removed glibc-static?

Yes, you would prevent us from being able to build static binaries for
the QEMU system emulators in Fedora QEMU packages. This in turn prevents
them from being used to provide seemless execution from non-native
architecture chroots / containers. This is used for example, by flatpack
to allow non-native architecture compilation, or as well as by myself
for various personal projects needing non-native compilation environments.
I agree there are many reasons why static libraries are a bad idea in
general, particularly the security implications, but they are none the
less useful at times and not every usage scenario has the same security
requirements.
NB, throwing out all the -static RPMs doesn't magically remove static
compilation from Fedora. There are entire non-C language toolchains in
Fedora that are based on static compilation - eg OCaml and Go

Yep, I maintain Rust which is one of these. But it does still default
to shared linking for libc and any other FFI.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email

[Richard W.M. Jones]

Post by Daniel P. Berrange
There are entire non-C language toolchains in
Fedora that are based on static compilation - eg OCaml

Although I'm nit-picking, this isn't entirely true.

OCaml doesn't statically link C code, as you can see from:

$ ldd /usr/bin/virt-builder
linux-vdso.so.1 (0x00007ffedf3e2000)
libguestfs.so.0 => /lib64/libguestfs.so.0 (0x00007fbc8210c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbc81eee000)
libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007fbc81cc2000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fbc81a8c000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fbc81866000)
libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fbc814fd000)
libyajl.so.2 => /lib64/libyajl.so.2 (0x00007fbc812f3000)
libm.so.6 => /lib64/libm.so.6 (0x00007fbc80fe2000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fbc80dde000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbc80bc7000)
[... continued for many more lines ...]

And even after that there are now options for dynamically linking
OCaml code, it's just that they're not very widely used upstream.
Since OCaml pays attention to safety this isn't so much of a problem
as with C.

Rich.

[Tomasz Kłoczko]

Post by Richard W.M. Jones
Although I'm nit-picking, this isn't entirely true.
$ ldd /usr/bin/virt-builder

[..]

So am I right that it looks like Ocaml can be removed as well from
glibc-static dependent packages? :)

kloczek

[Richard W.M. Jones]

Post by Tomasz Kłoczko

Post by Richard W.M. Jones
Although I'm nit-picking, this isn't entirely true.
$ ldd /usr/bin/virt-builder

[..]
So am I right that it looks like Ocaml can be removed as well from
glibc-static dependent packages? :)

I would very much prefer that you did not do anything until
you make an actual case for why the current situation is bad.

Rich.

[Richard W.M. Jones]

Post by Josh Stone
This may still be a useful consideration for Fedora itself. Would we
alienate anyone if Fedora removed glibc-static?

It would break supermin which compiles a tiny statically linked init.

Actually as of today we are using dietlibc instead of glibc-static on
every architecture that Fedora supports resulting in massive savings
in code size and performance:

https://koji.fedoraproject.org/koji/buildinfo?buildID=870395
https://github.com/libguestfs/supermin/blob/master/README#L148-L154

Rich.

[Tomasz Kłoczko]

Post by Richard W.M. Jones
It would break supermin which compiles a tiny statically linked init.
Actually as of today we are using dietlibc instead of glibc-static on
every architecture that Fedora supports resulting in massive savings

Did you try to link it against uClibc?
If t is about executable size depends which one libc functions linking with
uClibc should give you waay smaller binaries.
Please just try :)
*Install please uClibc-devel package and put -L%{_*libdir}/uClibc before
all -l<foo> parameters.

kloczek

[Richard W.M. Jones]

Post by Tomasz Kłoczko

Post by Richard W.M. Jones
It would break supermin which compiles a tiny statically linked init.
Actually as of today we are using dietlibc instead of glibc-static on
every architecture that Fedora supports resulting in massive savings

Did you try to link it against uClibc?

Yes, supermin supports several alternate libc.

Rich.

[Tomasz Kłoczko]

Post by Richard W.M. Jones

Post by Tomasz Kłoczko
Did you try to link it against uClibc?

Yes, supermin supports several alternate libc.

So it is -1 from critical glibc-static using projects :)

kloczek

[Richard W.M. Jones]

Post by Tomasz Kłoczko

Post by Richard W.M. Jones

Post by Tomasz Kłoczko
Did you try to link it against uClibc?

Yes, supermin supports several alternate libc.

So it is -1 from critical glibc-static using projects :)

I read through the whole thread and I still don't understand why
packaging glibc-static in Fedora is not a good thing.

Rich.

[Tomasz Kłoczko]

Post by Richard W.M. Jones
I read through the whole thread and I still don't understand why
packaging glibc-static in Fedora is not a good thing.

I've already described this multiple times trying to use different
descriptions/analogies about well known *glibc NSS ABI issue*.
You cannot fix this issue in *any libc implementation which is using NSS*.
IIRC NSS is anchored in SUSv3 specification and it affects every unices
libcs.
*Again: this is not only Linux issue and it was one of the reasons why it
is not possible to find in some unices libc.a!!!*
Other reasons are like constant changes in kernel<>userspace changes on all
unices are part of the problem as well.
Rarely one of those two things blows into the distributions maintainers
faces as *upgrades* will be affected by what must happen on those areas
during every OS evolutions.
It is *very easy* to *completely remove such risk*.

kloczek

[Daniel P. Berrange]

Post by Tomasz Kłoczko

Post by Richard W.M. Jones
I read through the whole thread and I still don't understand why
packaging glibc-static in Fedora is not a good thing.

I've already described this multiple times trying to use different
descriptions/analogies about well known *glibc NSS ABI issue*.
You cannot fix this issue in *any libc implementation which is using NSS*.

Apps don't need to make use of the affected APIs in glibc and even if they
do the problem is not a show stopper as long as you keep the app build in
sync. So while this is a potential problem, it is not a blocking problem
that justifies throwing the baby out with the bath water.

Post by Tomasz Kłoczko
Other reasons are like constant changes in kernel<>userspace changes on all
unices are part of the problem as well.

Linux doesn't constantly break kernel<->user ABI, so that's a non-issue.

Regards,
Daniel

[Tomasz Kłoczko]

Post by Daniel P. Berrange

Post by Tomasz Kłoczko
I've already described this multiple times trying to use different
descriptions/analogies about well known *glibc NSS ABI issue*.
You cannot fix this issue in *any libc implementation which is using

NSS*.
Apps don't need to make use of the affected APIs in glibc and even if they
do the problem is not a show stopper as long as you keep the app build in
sync. So while this is a potential problem, it is not a blocking problem
that justifies throwing the baby out with the bath water.

People are linking static binaries to not be forced to recompile and/or
relink such binaries.
In other words what you wrote is in contradiction with typical case when
static binaries are used.

Try to write simple "hello_nss" program communicating over network
establishing connectivity using host name.
Such program will be using network NSS map to resolve host name to IP over
"hosts" NSS map.
When you will have static binary try to execute "strace -e trace=file
./hello_nss" and you will see loading by such program libnss_dns.so and
libnss_files.so DSOs.
Such risk from NSS area is probably biggest in context of some random Linux
users trying to build and use 100% statically linked binaries.

Typical upgrade scenario with NSS issue which may hit hardly distribution
however is with other NSS maps.
In such upgrade scenario some programs are changing user and group during
upgrade on just written to the fs tree new files.
Such program will be using "passwd" and "group" NSS maps to resolve user
names and groups to UIDs and GIDs.

Post by Daniel P. Berrange
Other reasons are like constant changes in kernel<>userspace changes on all

Post by Tomasz Kłoczko
unices are part of the problem as well.

Linux doesn't constantly break kernel<->user ABI, so that's a non-issue.

Really? Hmm .. [censored =8-O] so it must be something really, really new
.. !!!
(OKi .. quick unpack glibc source code and .. )

[***@domek glibc-2.25-80-ga10e9c4]$ ./configure --help
`configure' configures GNU C Library (see version.h) to adapt to many
kinds of systems.

[..]

--enable-kernel=VERSION *compile for compatibility with kernel not older than
VERSION*

So please explain why in glibc autoconf still is such option? Can you do
this?
Maybe someone forgot to remove this option???
Just do what I did unpacking glibc source code and try to read
glibc ChangeLog* files looking for entries documenting some adjustments
between kernel API and glibc. This area is on constant move like lava.
~99.99% of the even highly skilled and experienced programmers may have
impression that everything here is still and static.
Yes, it is only .. impression!!! Thanks to LIBC all those changes are not
(usually) visible.
*This is one of the fundamental purposes of every Unix libc*!!!

http://stackoverflow.com/questions/11372872/what-the-role-of-libcglibc-in-our-linux-app
"You cannot directly make system calls in the same way that you call normal
functions because calls to the kernel aren't normal function calls, so they
can't be resolved by the linker. Instead, architecture-specific assembly
language thunks are used to call into the kernel - you can of course write
these directly in your own program too, but you don't need to because libc
provides them for you."

And one more time ..
Did you had a look on Documentation/ABI content in kernel source tree?
Did you read with understanding paragraph from Documentation/ABI/README
which I've quoted in this thread?


Please don't get me wrong. I'm not trying to attack you personally even if
it may look that I'm doing exactly this.
This discussion is on pure technical/engineering background.
I'm a bit frustrated or anger that I'm not able to express such subject
enough clearly ..
(I'm not native English speaker and if we will be talking using Polish it
would be way easier to me :) )

So .. Daniel you are working in RedHat. So .. in RedHat probably still is
working *Ulrich Drepper* who is glibc maintainer.
Offer him free lunch to have opportunity to talk with him face about this
subject (you can send me the bill after all :) ).
You can do this because if not every day probably time to time you can have
him on "normal beret throwing distance".
(I'm in UK so I would be forced to use ballistic beret).

Please don't try to convince me. Rally forget about me. I'm probably one of
the smallest beatles here.
Just please sit down with him and try to convince *him* that there is no at
all risk here.

kloczek

[Daniel P. Berrange]

Post by Tomasz Kłoczko

Post by Daniel P. Berrange

Post by Tomasz Kłoczko
I've already described this multiple times trying to use different
descriptions/analogies about well known *glibc NSS ABI issue*.
You cannot fix this issue in *any libc implementation which is using

NSS*.
Apps don't need to make use of the affected APIs in glibc and even if they
do the problem is not a show stopper as long as you keep the app build in
sync. So while this is a potential problem, it is not a blocking problem
that justifies throwing the baby out with the bath water.

People are linking static binaries to not be forced to recompile and/or
relink such binaries.
In other words what you wrote is in contradiction with typical case when
static binaries are used.
Try to write simple "hello_nss" program communicating over network
establishing connectivity using host name.
Such program will be using network NSS map to resolve host name to IP over
"hosts" NSS map.
When you will have static binary try to execute "strace -e trace=file
./hello_nss" and you will see loading by such program libnss_dns.so and
libnss_files.so DSOs.
Such risk from NSS area is probably biggest in context of some random Linux
users trying to build and use 100% statically linked binaries.
Typical upgrade scenario with NSS issue which may hit hardly distribution
however is with other NSS maps.
In such upgrade scenario some programs are changing user and group during
upgrade on just written to the fs tree new files.
Such program will be using "passwd" and "group" NSS maps to resolve user
names and groups to UIDs and GIDs.

I never said anything about either needing to upgrade or needing to resolve
hostnames / user names / group names.

I use Fedora to build statically linked binaries for certain embedded
devices I build and they have no network connectivity, nor need to have
user/group lookups. Nor do they receive yum updates. When I update the
software, I simply build it again on latest Fedora packages. So the
problem you describe are a non-issue in my usage of static libraries.

Post by Tomasz Kłoczko

Post by Daniel P. Berrange
Other reasons are like constant changes in kernel<>userspace changes on all

Post by Tomasz Kłoczko
unices are part of the problem as well.

Linux doesn't constantly break kernel<->user ABI, so that's a non-issue.

Really? Hmm .. [censored =8-O] so it must be something really, really new
.. !!!
(OKi .. quick unpack glibc source code and .. )
`configure' configures GNU C Library (see version.h) to adapt to many
kinds of systems.
[..]
--enable-kernel=VERSION *compile for compatibility with kernel not older than
VERSION*
So please explain why in glibc autoconf still is such option? Can you do
this?

Some system calls are found to be broken by design & not extensible. In those
cases Linux may introduces new syscalls with improved design to replace them.
The old syscalls still exist in Linux. GLibc could try the new syscall, and
fallback to the old syscall if missing. The configure arg is just a way to
drop the fallback code if the platform doesn't need to care about running
with old kernels. Linux hasn't broken ABI compatibility here - on the contrary
it has intentionally maintained ABI compatibility by introducing a new syscall
in parallel with the existing syscall, instead of simply changing the original
syscall.

Post by Tomasz Kłoczko
So .. Daniel you are working in RedHat. So .. in RedHat probably still is
working *Ulrich Drepper* who is glibc maintainer.

Ulrich hasn't worked for Red Hat for many many many years.

Post by Tomasz Kłoczko
Offer him free lunch to have opportunity to talk with him face about this
subject (you can send me the bill after all :) ).
You can do this because if not every day probably time to time you can have
him on "normal beret throwing distance".
(I'm in UK so I would be forced to use ballistic beret).
Please don't try to convince me. Rally forget about me. I'm probably one of
the smallest beatles here.
Just please sit down with him and try to convince *him* that there is no at
all risk here.

I'm not saying there is no risk. No one has ever suggested it works perfectly
in all scenarios. I'm simply saying that there *are* valid usage scenarios
where it works just fine and thus deleting this support from Fedora is
wrong.

Regards,
Daniel

[Tomasz Kłoczko]

Post by Daniel P. Berrange

Post by Tomasz Kłoczko
Please don't try to convince me. Rally forget about me. I'm probably one

of

Post by Tomasz Kłoczko
the smallest beatles here.
Just please sit down with him and try to convince *him* that there is no

at

Post by Tomasz Kłoczko
all risk here.

I'm not saying there is no risk. No one has ever suggested it works perfectly
in all scenarios. I'm simply saying that there *are* valid usage scenarios
where it works just fine and thus deleting this support from Fedora is
wrong.

I fully understand your point of view however context on which you are
trying to gently gently move subject is not enough/proper.
I have enough knowledge about this area because as someone working been in
the past on full scale Linux distribution and coordinating most of the
movements I've hit this issue two times. There is only handful people like
me with enough knowledge about risk linking statically with glibc libc.a
(libm.a has own issues as well).
However my knowledge about details here is maybe less than 1% of what
Ulrich has in his head and if someone want to cut this knot please ask him
for expertise.

Discussing this subject longer here IMO does not make to much sense.
I've quoted enough details here to give more people enough details to grind
this subject in context of facts.

Will try to make some packages changes to remove as much as I can other
static libraries.
This task can be scaled across many even average Fedora packagers and this
email is about encourage other packagers to have closer look on own
packages to make some changes. If someone will have some doubts about
something related to the subject please contact me via email or on freenode
IRC.
There is plenty to do here and current Fedora packaging policy is fully
compliant with what I've been trying to tell about other than glibc static
libraries.
*What is already inked in Fedora policies needs only to be finished ..
nothing more.*

What I can promise here is that time to time will try to observe how things
are changing in Fedora to analyse current state and write some short report.
In next few days will try to write a bit more detailed report about current
state to stamp current state to observe how things are changing.

From my side EOT .. if no one have anything new to add (?)

kloczek

[Kevin Kofler]

Post by Daniel P. Berrange
Ulrich hasn't worked for Red Hat for many many many years.

As far as I know, he works for Goldman Sachs now.

He is also no longer "the glibc maintainer". There are now a whole bunch of
people responsible:
https://sourceware.org/glibc/wiki/MAINTAINERS

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fe

[Tomasz Kłoczko]

you should try to understand what you quote and refer to - this options is
there *to break that compatibility which is otherwise implicit enabled*

Original claim which I've commented was about that Linux (kernel) does not
changes anything in user<>kernel space interface.
So I've presented something which shows that it is not truth.
It was not about using such option on glibc build stage to break such
compatibility.

BTW. In case Linux glibc binary code is ballooned by the fact as long as
you are not enabling source code configuration time option glibc code is
ready to work probably even with kernels 2.0.x or at least 2.4/2.6.
Other OSes distributions (not only Unixes) are assuming that kernel and
base libraries are changing within system image as unbreakable resource so
libc supports only supports current version of the kernel.
Especially on Solaris such approach is possible as ZFS offers BEs (Boot
Environments) in which may exist independent pairs of kernels<>libc.
BSD* after incorporating ZFS into mainline uses exactly the same approach.
THIS makes maintenance of the libc code dramatically simpler.

In last ten years I heard many times BSD* and Solaris guys making jokes
about glibc developers about supporting in single binary every possible
kernel version.
It does not mean that I share such point of view .. it is more that now I
understand better from where it comes and why some other Unixes made move
to which Linux still seems is not ready.

As the same approach is possible to implement now on top of Linux with
btrfs maybe some people will start thinking about similar changes (?)
In recent years when I've been mentioning abut such possibility quite often.
As an argument was usually used that ext or xfs code is smaller than btrfs.
Surprisingly it is not true as code of these FSeses must handle quite long
ladder of older version of ext and xfs file systems.
IMO sooner or later some people will understand that some more radical
changes needs to be done on top of the Linux as well.
This fact is a bit unexpected as originally Linux was developed as well as
king protest to keeping some legacy compatibility in other proprietary
Unixes.
Seems after 25 years Linux have now some significant legacy which is a bit
weighting it down ..

and BTW you are the only guy in the whole thread which converts each repoly

to HTML and it is *annoying* because you have no business to dedice in
which font and size others MUA render messages

Don't want to be rude but it means that you are still using email today
like people +30 years ago.
In the past I've invested few times personally time to adapt some email
clients to be able handle correctly MIME.
In other words you are trying to tell me that my past investment was
pointless .. ;)

Really it is time to move on because today email communication is about
efficiency and speed, and not about still using plain SMTP messages.
If your email client is not able to map font names to some other names it
is not a feature but BUG in such client. Try to report this.
There are already many OSS implementations showing how to handle such
scenarios.
Cannot find quickly how to disable HTML in replies. I promise that I'll
find a way how to not send such emails here next time.

kloczek

[Xose Vazquez Perez]

Post by Tomasz Kłoczko
Did you try to link it against uClibc?
If t is about executable size depends which one libc functions linking with
uClibc should give you waay smaller binaries.
Please just try :)
*Install please uClibc-devel package and put -L%{_*libdir}/uClibc before
all -l<foo> parameters.

You should consider switching to uClibc-ng [1].
uClibc project is frozen, latest release [2] was done five years ago and last
git commit [3] nearly two.

[1] https://www.uclibc-ng.org/
[2] https://www.uclibc.org/news.html
[3] https://git.uclibc.org/uClibc/log/
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscri

[Tomasz Kłoczko]

Post by Xose Vazquez Perez
You should consider switching to uClibc-ng [1].
uClibc project is frozen, latest release [2] was done five years ago and last
git commit [3] nearly two.

Than you for putting one more useful pebble in the my hands :)

kloczek

[Florian Weimer]

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

This is not the right list for discussing Red Hat Enterprise Linux
matters, but please be advised that the above statement shall not be
interpreted in such a way that indicates that static linking of glibc is
supported on Red Hat Enterprise Linux.

Thanks,
Florian
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscr

[Jonathan Wakely]

Post by Florian Weimer

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.

This is not the right list for discussing Red Hat Enterprise Linux
matters, but please be advised that the above statement shall not be
interpreted in such a way that indicates that static linking of glibc
is supported on Red Hat Enterprise Linux.

Right, that's definitely not what I meant.

There are people who use the static libraries, for their own reasons,
and don't expect support when they do so.

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@l

[Tomasz Kłoczko]

Post by Jonathan Wakely
There are people who use the static libraries, for their own reasons,
and don't expect support when they do so.

I can only repeat that such people should consider linking own binaries
against uClibc as this implementation is not affected by issue with hidden
loading NSS DSOs which probably make such binaries useless on moving around
against latest fedora/RH7 and RH5.

Even at the end and idea of dropping building and providing glibc-static
will be not accepted at least current list of packages which are using
static linking with glibc libraries should be carefully reviewed. Looking
on not full list of spec files which have listed "BuildRequires:
glibc-static" i see for example mdadm abandoned static linking and again ..
no one is crying about this.
Definitely almost all of the those +190 static packages can be abandoned
without even single change in other Fedora spec files.

So far most of the cases which already found are using static linking with
glibc is related to some test suits.
For example only binutils provides ld and ld-gold and they are responsible
for linking with other libraries, and software like golang probably should
not be doing own static linking tests because for such static linking is
responsible binutils ld.

kloczek

[Michael Cronenworth]

Please turn off HTML in GMail.

I can only repeat that such people should consider linking own binaries against
uClibc as this implementation is not affected by issue with hidden loading NSS
DSOs which probably make such binaries useless on moving around against latest
fedora/RH7 and RH5.

Let's cut to the chase: You don't like glibc. OK. Do we need to create a 100+ email
chain to thousands of Fedora developers who have more important things to do in
their day? Feel free to discuss this on your blog or another medium.

Even at the end and idea of dropping building and providing glibc-static will be
not accepted at least current list of packages which are using static linking with
glibc libraries should be carefully reviewed. Looking on not full list of spec
files which have listed "BuildRequires: glibc-static" i see for example mdadm
abandoned static linking and again .. no one is crying about this.
Definitely almost all of the those +190 static packages can be abandoned without
even single change in other Fedora spec files.

You'll have to do better than "because I don't like it." Just yesterday I had to
create a binary that was SLES 10 compatible and thank-the-lord I had static
libraries available in RHEL5 to be able to do it. There will be really strange cases
that need static libraries around. They are not hurting anyone by having them
present. Note: The previous sentence was brought to you buy a dynamic library supporter.

So far most of the cases which already found are using static linking with glibc
is related to some test suits.
For example only binutils provides ld and ld-gold and they are responsible for
linking with other libraries, and software like golang probably should not be
doing own static linking tests because for such static linking is responsible
binutils ld.

Those test suites are only executed during build time in Koji. They're not hurting
you or any other Fedora user.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deve

[Tomasz Kłoczko]

OK here is full list of spec files which have glibc-static in BuildRequires:

./g/gcc.git/gcc.spec:BuildRequires: glibc-static
./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}
./g/gdb.git/gdb.spec:# multilib glibc-static is open Bug 488472:
./g/gdb.git/gdb.spec:#BuildRequires: glibc-static%{bits_other}
./g/glibc.git/glibc.spec:# before glibc is built and therefore we need
a glibc-static for that
./g/glibc.git/glibc.spec:BuildRequires: glibc-static
./g/glibc.git/glibc.spec:The glibc-static package contains the C
library static libraries
./g/glibc.git/glibc.spec:- Require glibc-static for C++ tests.
./g/glibc.git/glibc.spec:- Require gcc-c++, libstdc++-static, and
glibc-static only when needed.
./g/golang.git/golang.spec:BuildRequires: pcre-devel, glibc-static, perl
./g/grub2.git/grub2.spec:BuildRequires: /usr/lib64/crt1.o glibc-static
./g/grub2.git/grub2.spec:BuildRequires: /usr/lib/crt1.o glibc-static
./b/binutils.git/binutils.spec:BuildRequires: dejagnu, zlib-static,
glibc-static, sharutils, bc
./b/binutils.git/binutils.spec:- Add glibc-static to BuildRequires
when running the testsuite.
./b/busybox.git/busybox.spec:BuildRequires: glibc-static
./c/cadvisor.git/cadvisor.spec:BuildRequires: glibc-static
./c/chkrootkit.git/chkrootkit.spec:BuildRequires: glibc-static
./c/chkrootkit.git/chkrootkit.spec:- Fedora > 10: conditional BR
glibc-static as needed for strings-static
./c/compat-gcc-296.git/compat-gcc-296.spec:BuildRequires: glibc-devel

= 2.2.90-12, glibc-static

./c/compat-gcc-32.git/compat-gcc-32.spec:BuildRequires: glibc-devel >=
2.2.90-12, glibc-static
./c/cscppc.git/cscppc.spec:BuildRequires: glibc-static
./c/cswrap.git/cswrap.spec:BuildRequires: glibc-static
./d/docker.git/docker.spec:BuildRequires: glibc-static
./d/docker-latest.git/docker-latest.spec:BuildRequires: glibc-static
./d/dyninst.git/dyninst.spec:BuildRequires: gcc-gfortran glibc-static
libstdc++-static nasm
./d/dyninst.git/dyninst.spec:Requires: glibc-static
./e/efivar.git/efivar.spec:BuildRequires: popt-devel popt-static git
glibc-static libabigail
./k/kexec-tools.git/kexec-tools.spec:- Add BR glibc-static
./l/libguestfs.git/libguestfs.spec:BuildRequires: glibc-static
./l/libguestfs.git/libguestfs.spec:- BRs glibc-static for the new command tests.
./l/libhugetlbfs.git/libhugetlbfs.spec:BuildRequires: glibc-static
./l/libibmad.git/libibmad.spec:BuildRequires: glibc-static
./l/libibumad.git/libibumad.spec:BuildRequires: glibc-static
./l/libibumad.git/libibumad.spec:- Add build requires on glibc-static
./l/libvirt-sandbox.git/libvirt-sandbox.spec:BuildRequires: glibc-static
./m/mash.git/mash.spec:- allow glibc-static as a devel package
./m/mdadm.git/mdadm.spec:- Remove the glibc-static buildreq and don't
build the static mdadm since
./n/nacl-arm-binutils.git/nacl-arm-binutils.spec:BuildRequires:
dejagnu, zlib-static, glibc-static, sharutils
./n/nacl-binutils.git/nacl-binutils.spec:BuildRequires: dejagnu,
zlib-static, glibc-static, sharutils
./o/ocid.git/ocid.spec:BuildRequires: glibc-static
./o/ORBit.git/ORBit.spec:BuildRequires: glibc-static
./o/ORBit.git/ORBit.spec:- BR: glibc-static for EL-6 onwards
./o/ORBit.git/ORBit.spec:- Buildreq glibc-static for test code in
bundled popt library (F-11 onwards)
./q/qemu-sanity-check.git/qemu-sanity-check.spec:BuildRequires: glibc-static
./q/qemu.git/qemu.spec:BuildRequires: glibc-static pcre-static
glib2-static zlib-static
./r/redhat-lsb.git/redhat-lsb.spec:BuildRequires: glibc-static
./r/rkt.git/rkt.spec:BuildRequires: glibc-static
./s/scantailor.git/scantailor.spec:BuildRequires: glibc-static
./s/supermin.git/supermin.spec:# To use glibc-static instead, do
``--without dietlibc''. This
./s/supermin.git/supermin.spec:BuildRequires: glibc-static
./s/supermin.git/supermin.spec:- Enable dietlibc, remove glibc-static,
xz-static, zlib-static.
./s/supermin.git/supermin.spec:- New BRs on mke2fs, libext2fs, glibc-static.


Looking on this list without looking deeper into the packages it is easy to
figure out that almost half of the glibc-static using cases are related to
test suits.

BTW I found current Fedora guidelines about static linking and static
libraries and they are already forming set of rules which are recommending
what I've wrote here
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

In other words such subject has been discussed already and I'm not the only
one who is thinking that cutting to absolute minimum using static linking
and provide static libraries is right direction and/or thinking that Fedora
already provides some env to produce statically linked binaries is more or
less only kind of wrong impression.

And yet another grep output (this time a bit longer) which shows which
packages are using other packages static libraries:

./g/gcc.git/gcc.spec:BuildRequires: glibc*-static*
./g/gcl.git/gcl.spec:BuildRequires: binutils*-static*
./g/gdal.git/gdal.spec:BuildRequires: g2clib*-static*
./g/gdal.git/gdal.spec:BuildRequires: hdf*-static*
./g/gdb.git/gdb.spec:BuildRequires: glibc*-static*%{bits_local}
./g/gdl.git/gdl.spec:BuildRequires: fftw-devel, hdf*-static*
./g/gdl.git/gdl.spec:BuildRequires: grib_api*-static*
./g/gdl.git/gdl.spec:BuildRequires: eigen3*-static*
./g/ghdl.git/ghdl.spec:BuildRequires: llvm*-static*
./g/glabels.git/glabels.spec:BuildRequires: barcode*-static*
./g/glibc.git/glibc.spec:BuildRequires: libstdc++*-static*
./g/glibc.git/glibc.spec:BuildRequires: glibc*-static*
./g/gob2.git/gob2.spec:BuildRequires: flex*-static*
./g/golang.git/golang.spec:BuildRequires: pcre-devel, glibc*-static*, perl
./g/gprbuild.git/gprbuild.spec:BuildRequires: xmlada*-static* gprbuild
./g/gprbuild.git/gprbuild.spec:BuildRequires: libgnat*-static* >= 6.1
./g/grads.git/grads.spec:BuildRequires: hdf*-static* hdf-devel
hdf5-devel netcdf-devel
./g/grads.git/grads.spec:BuildRequires: g2clib*-static* g2clib-devel
./g/greenisland.git/greenisland.spec:BuildRequires:
qt5-qtbase*-static* >= 5.5.0
./g/grub2.git/grub2.spec:BuildRequires: /usr/lib64/crt1.o glibc*-static*
./g/grub2.git/grub2.spec:BuildRequires: /usr/lib/crt1.o glibc*-static*
./a/appmenu-qt5.git/appmenu-qt5.spec:BuildRequires: qt5-qtbase*-static*
./a/ardour5.git/ardour5.spec:BuildRequires: qm-dsp*-static*
./a/at.git/at.spec:BuildRequires: flex flex*-static* bison autoconf
./a/atlas.git/atlas.spec:BuildRequires: gcc-gfortran, lapack*-static*
./a/avarice.git/avarice.spec:BuildRequires: binutils*-static*, libusb-devel
./b/b43-tools.git/b43-tools.spec:BuildRequires: flex flex*-static*
./b/bcc.git/bcc.spec:BuildRequires: elfutils-libelf-devel*-static*
./b/bcc.git/bcc.spec:BuildRequires: llvm-devel llvm*-static* clang-devel
./b/bes.git/bes.spec:BuildRequires: hdf*-static*
./b/binutils.git/binutils.spec:BuildRequires: dejagnu, zlib*-static*,
glibc*-static*, sharutils, bc
./b/binutils.git/binutils.spec:BuildRequires: libstdc++*-static*
./b/bsd-games.git/bsd-games.spec:BuildRequires: ncurses-devel words
flex flex*-static* bison
./b/busybox.git/busybox.spec:BuildRequires: libselinux*-static*
./b/busybox.git/busybox.spec:BuildRequires: libsepol*-static*
./b/busybox.git/busybox.spec:BuildRequires: glibc*-static*
./b/busybox.git/busybox.spec:BuildRequires: uClibc*-static*
./c/cadvisor.git/cadvisor.spec:BuildRequires: glibc*-static*
./c/calibre.git/calibre.spec:BuildRequires: qt5-qtbase*-static*
./c/castxml.git/castxml.spec:BuildRequires: llvm*-static* >= 3.6.0
./c/ceres-solver.git/ceres-solver.spec:BuildRequires: eigen3*-static* >= 3.2.1
./c/check-mk.git/check-mk.spec:BuildRequires: libstdc++*-static*
./c/checkpolicy.git/checkpolicy.spec:BuildRequires: byacc bison flex
flex*-static* libsepol*-static* >= %{libsepolver} libselinux-devel >=
%{libselinuxver}
./c/chkrootkit.git/chkrootkit.spec:BuildRequires: glibc*-static*
./c/clang.git/clang.spec:BuildRequires: llvm*-static* = %{version}
./c/collectd.git/collectd.spec:BuildRequires: iproute*-static*, libmnl-devel
./c/compat-gcc-296.git/compat-gcc-296.spec:BuildRequires: glibc-devel

= 2.2.90-12, glibc*-static*

./c/compat-gcc-32.git/compat-gcc-32.spec:BuildRequires: glibc-devel >=
2.2.90-12, glibc*-static*
./c/compiler-rt.git/compiler-rt.spec:BuildRequires: llvm*-static* = %{version}
./c/COPASI.git/COPASI.spec:BuildRequires: libkdeedu*-static*
./c/cscppc.git/cscppc.spec:BuildRequires: glibc*-static*
./c/csound.git/csound.spec:BuildRequires: eigen3*-static*
./c/cswrap.git/cswrap.spec:BuildRequires: glibc*-static*
./d/detox.git/detox.spec:BuildRequires: flex flex*-static*
./d/docker.git/docker.spec:BuildRequires: glibc*-static*
./d/docker.git/docker.spec:BuildRequires: libseccomp*-static* >= 2.3.0
./d/docker-latest.git/docker-latest.spec:BuildRequires: glibc*-static*
./d/docker-latest.git/docker-latest.spec:BuildRequires:
libseccomp*-static* >= 2.3.0
./d/dropwatch.git/dropwatch.spec:BuildRequires: binutils-devel,
binutils*-static* libnl3-devel pkgconfig
./d/dx.git/dx.spec:BuildRequires: hdf*-static*, hdf-devel
./d/dyninst.git/dyninst.spec:BuildRequires: gcc-gfortran
glibc*-static* libstdc++*-static* nasm
./e/ecl.git/ecl.spec:BuildRequires: libatomic_ops*-static*
./e/efivar.git/efivar.spec:BuildRequires: popt-devel popt*-static*
git glibc*-static* libabigail
./e/esc.git/esc.spec:BuildRequires: nspr-devel nss-devel nss*-static*
./f/fifechan.git/fifechan.spec:BuildRequires: SDL2*-static*
./f/firebird.git/firebird.spec:BuildRequires: libstdc++*-static*
./f/firefox.git/firefox.spec:BuildRequires: nss*-static* >= %{nss_version}
./f/fldigi.git/fldigi.spec:BuildRequires: fltk*-static* libXcursor-devel
./f/fped.git/fped.spec:BuildRequires: flex*-static*
./i/icecat.git/icecat.spec:BuildRequires: nss-devel, nss*-static*
./i/indi-aagcloudwatcher.git/indi-aagcloudwatcher.spec:BuildRequires:
libindi*-static*
./i/indi-apogee.git/indi-apogee.spec:BuildRequires: libindi*-static*
libindi-devel libapogee-devel libnova-devel
./i/indi-eqmod.git/indi-eqmod.spec:BuildRequires: libindi*-static*
./i/indi-gphoto.git/indi-gphoto.spec:BuildRequires: libindi*-static*
./i/indi-sx.git/indi-sx.spec:BuildRequires: libindi*-static*
./i/ipsec-tools.git/ipsec-tools.spec:BuildRequires: openssl-devel,
krb5-devel, bison, flex, flex*-static*
./i/iscsi-initiator-utils.git/iscsi-initiator-utils.spec:BuildRequires:
isns-utils*-static* isns-utils-devel
./i/iwyu.git/iwyu.spec:BuildRequires: llvm*-static*
./j/jhdf5.git/jhdf5.spec:BuildRequires: hdf*-static*
./j/js-jquery1.git/js-jquery1.spec:BuildRequires: js-sizzle*-static*
./j/js-jquery.git/js-jquery.spec:BuildRequires: js-sizzle*-static*
./k/kde-dev-utils.git/kde-dev-utils.spec:BuildRequires:
binutils-devel binutils*-static*
./k/kdepim3.git/kdepim3.spec:BuildRequires: bison flex flex*-static*
./k/kexec-tools.git/kexec-tools.spec:BuildRequires: zlib-devel zlib
zlib*-static* elfutils-devel*-static* glib2-devel bzip2-devel
ncurses-devel bison flex lzo-devel snappy-devel
./k/kf5-kdesignerplugin.git/kf5-kdesignerplugin.spec:BuildRequires:
qt5-qttools*-static*
./k/kf5-kholidays.git/kf5-kholidays.spec:BuildRequires: qt5-qttools*-static*
./k/kf5-kjsembed.git/kf5-kjsembed.spec:BuildRequires: qt5-qttools*-static*
./k/kf5-kross.git/kf5-kross.spec:BuildRequires: qt5-qttools*-static*
./k/kf5-kwidgetsaddons.git/kf5-kwidgetsaddons.spec:BuildRequires:
qt5-qttools*-static*
./k/kstars.git/kstars.spec:BuildRequires: pkgconfig(libindi) >= 1.3.1,
libindi*-static*
./k/kwin.git/kwin.spec:BuildRequires: qt5-qtbase*-static*
./k/kwin.git/kwin.spec:BuildRequires: qt5-qttools*-static*
./l/latrace.git/latrace.spec:BuildRequires: autoconf bison asciidoc
xmlto binutils-devel binutils*-static*
./l/ldc.git/ldc.spec:BuildRequires: llvm*-static*
./l/libguestfs.git/libguestfs.spec:BuildRequires: glibc*-static*
./l/libhugetlbfs.git/libhugetlbfs.spec:BuildRequires: glibc*-static*
./l/libibmad.git/libibmad.spec:BuildRequires: glibc*-static*
./l/libibumad.git/libibumad.spec:BuildRequires: glibc*-static*
./l/libkgapi.git/libkgapi.spec:BuildRequires: qt5-qttools*-static*
./l/libmatheval.git/libmatheval.spec:BuildRequires: gcc-gfortran,
compat-guile18-devel, bison, flex, flex*-static*, texinfo
./l/libopensync-plugin-synce.git/libopensync-plugin-synce.spec:BuildRequires:
libmimedir-devel libmimedir*-static*
./l/libosmium.git/libosmium.spec:BuildRequires: protozero*-static*
./l/libosmium.git/libosmium.spec:BuildRequires: gdalcpp*-static*
./l/libosmium.git/libosmium.spec:BuildRequires: utf8cpp*-static*
./l/librra.git/librra.spec:BuildRequires: libmimedir-devel libmimedir*-static*
./l/libselinux.git/libselinux.spec:BuildRequires: python python-devel
ruby-devel ruby libsepol*-static* >= %{libsepolver} swig pcre-devel
xz-devel
./l/libtpms.git/libtpms.spec:BuildRequires:
nss-softokn-freebl*-static* >= 3.12.9-2
./l/libvirt-sandbox.git/libvirt-sandbox.spec:BuildRequires: glibc*-static*
./l/libvirt-sandbox.git/libvirt-sandbox.spec:BuildRequires: xz-devel

= 5.0.0, xz*-static*

./l/libvirt-sandbox.git/libvirt-sandbox.spec:BuildRequires: zlib-devel

= 1.2.0, zlib*-static*

./l/linux-atm.git/linux-atm.spec:BuildRequires: byacc automake libtool
flex flex*-static*
./l/linuxdoc-tools.git/linuxdoc-tools.spec:BuildRequires: flex
flex*-static* sgml-common jade gawk groff autoconf texinfo
./l/lldb.git/lldb.spec:BuildRequires: llvm*-static* = %{version}
./l/llvm.git/llvm.spec:BuildRequires: libstdc++*-static*
./l/llvm3.9.git/llvm3.9.spec:BuildRequires: libstdc++*-static*
./l/lv2-EQ10Q-plugins.git/lv2-EQ10Q-plugins.spec:BuildRequires:
lv2-c++-tools*-static*
./l/lv2-ll-plugins.git/lv2-ll-plugins.spec:BuildRequires: lv2-c++-tools*-static*
./l/lv2-mdaEPiano.git/lv2-mdaEPiano.spec:BuildRequires: lv2-c++-tools*-static*
./m/Macaulay2.git/Macaulay2.spec:BuildRequires: cddlib-devel cddlib*-static*
./m/Macaulay2.git/Macaulay2.spec:BuildRequires: factory*-static*
factory-devel >= 3.1.6
./m/Macaulay2.git/Macaulay2.spec:BuildRequires: libfac*-static*
libfac-devel >= 3.1.6
./m/mcstrans.git/mcstrans.spec:BuildRequires: libcap-devel pcre-devel
libsepol-devel libsepol*-static*
./m/mesa.git/mesa.spec:BuildRequires: libstdc++*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-dbus*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-libjpeg-turbo*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-libtiff*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-libpng*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-sqlite*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-zlib*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw32-winpthreads*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-dbus*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-libjpeg-turbo*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-libtiff*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-libpng*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-sqlite*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-zlib*-static*
./m/mingw-qt.git/mingw-qt.spec:BuildRequires: mingw64-winpthreads*-static*
./m/mingw-qt5-qt3d.git/mingw-qt5-qt3d.spec:BuildRequires:
mingw32-qt5-qtbase*-static*
./m/mingw-qt5-qt3d.git/mingw-qt5-qt3d.spec:BuildRequires:
mingw64-qt5-qtbase*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw32-dbus*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw32-harfbuzz*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw32-pcre*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw32-sqlite*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw32-winpthreads*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw64-dbus*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw64-harfbuzz*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw64-pcre*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw64-sqlite*-static*
./m/mingw-qt5-qtbase.git/mingw-qt5-qtbase.spec:BuildRequires:
mingw64-winpthreads*-static*
./m/mingw-qt5-qtdeclarative.git/mingw-qt5-qtdeclarative.spec:BuildRequires:
mingw32-qt5-qtbase*-static*
./m/mingw-qt5-qtdeclarative.git/mingw-qt5-qtdeclarative.spec:BuildRequires:
mingw64-qt5-qtbase*-static*
./m/mingw-wine-gecko.git/mingw-wine-gecko.spec:BuildRequires:
mingw64-winpthreads*-static*
./m/mingw-wine-gecko.git/mingw-wine-gecko.spec:BuildRequires:
mingw32-winpthreads*-static*
./m/mod_revocator.git/mod_revocator.spec:BuildRequires:
nss-pkcs11-devel*-static*
./m/motif.git/motif.spec:BuildRequires: flex*-static*
./m/mrpt.git/mrpt.spec:BuildRequires: eigen3*-static*
./m/mscore.git/mscore.spec:BuildRequires: qt5-qttools*-static*
./m/mutrace.git/mutrace.spec:BuildRequires: binutils*-static*
./n/nacl-arm-binutils.git/nacl-arm-binutils.spec:BuildRequires:
dejagnu, zlib*-static*, glibc*-static*, sharutils
./n/nacl-binutils.git/nacl-binutils.spec:BuildRequires: dejagnu,
zlib*-static*, glibc*-static*, sharutils
./n/nagi.git/nagi.spec:BuildRequires: docbook-utils, SDL-devel, SDL*-static*
./n/ncl.git/ncl.spec:BuildRequires: hdf*-static*, hdf-devel >= 4.2r2
./n/ncl.git/ncl.spec:BuildRequires: g2clib*-static*
./n/ncl.git/ncl.spec:BuildRequires: flex*-static*
./n/nemiver.git/nemiver.spec:BuildRequires: boost*-static*
./n/netcdf.git/netcdf.spec:BuildRequires: hdf*-static*
./n/nethack-vultures.git/nethack-vultures.spec:BuildRequires: SDL*-static*
./n/nodejs-connect.git/nodejs-connect.spec:BuildRequires: npm(serve*-static*)
./n/nodejs-grunt-contrib-connect.git/nodejs-grunt-contrib-connect.spec:BuildRequires:
npm(serve*-static*)
./n/nodejs-mapnik.git/nodejs-mapnik.spec:BuildRequires:
mapnik*-static* >= 3.0.12
./n/nodejs-mapnik-vector-tile.git/nodejs-mapnik-vector-tile.spec:BuildRequires:
mapnik*-static* >= 3.0.12
./o/ocid.git/ocid.spec:BuildRequires: glibc*-static*
./o/ocid.git/ocid.spec:BuildRequires: libseccomp*-static*
./o/openblas.git/openblas.spec:BuildRequires: lapack*-static*%{?_isa}
./o/openblas.git/openblas.spec:BuildRequires: lapack64*-static*
./o/openlierox.git/openlierox.spec:BuildRequires: binutils*-static*
./o/opentracker.git/opentracker.spec:BuildRequires: libowfat*-static*
./o/oprofile.git/oprofile.spec:BuildRequires: binutils*-static*
./o/ORBit.git/ORBit.spec:BuildRequires: glibc*-static*
./o/orsa.git/orsa.spec:BuildRequires: mpich-devel*-static*
./o/osmium-tool.git/osmium-tool.spec:BuildRequires:
libosmium*-static* >= %{libosmium_version}
./o/osmium-tool.git/osmium-tool.spec:BuildRequires:
rapidjson*-static* >= %{rapidjson_version}
./p/papi.git/papi.spec:BuildRequires: libpfm*-static* >= 4.6.0-1
./p/pcl.git/pcl.spec:BuildRequires: eigen3*-static*, flann-devel,
cminpack-devel, vtk-devel, gl2ps-devel, hdf5-devel, python-devel,
libxml2-devel, netcdf-cxx-devel, jsoncpp-devel, metslib*-static*
./p/percolator.git/percolator.spec:BuildRequires: boost148*-static*,
boost148-devel
./p/percolator.git/percolator.spec:BuildRequires: boost*-static*, boost-devel
./p/perl-CBOR-XS.git/perl-CBOR-XS.spec:BuildRequires: libecb*-static*
./p/perl-Compress-LZF.git/perl-Compress-LZF.spec:BuildRequires:
perlmulticore*-static*
./p/perl-Coro.git/perl-Coro.spec:BuildRequires: libecb*-static*
./p/perl-PDL.git/perl-PDL.spec:BuildRequires: hdf*-static* hdf-devel
./p/plasma-integration.git/plasma-integration.spec:BuildRequires:
qt5-qtbase*-static*
./p/plasma-nm.git/plasma-nm.spec:BuildRequires: qt5-qttools*-static*
./p/policycoreutils.git/policycoreutils.spec:BuildRequires: pam-devel
libcgroup-devel libsepol*-static* >= %{libsepolver}
libsemanage*-static* >= %{libsemanagever} libselinux-devel >=
%{libselinuxver} libcap-devel audit-libs-devel >= %{libauditver}
gettext
./p/polymake.git/polymake.spec:BuildRequires: eigen3*-static*
./p/ppl.git/ppl.spec:BuildRequires: pl >= 5.10.2-3, pl-devel >=
5.10.2-3, pl*-static* >= 5.10.2-3
./p/psi4.git/psi4.spec:BuildRequires: pybind11*-static*
./p/pulseaudio.git/pulseaudio.spec:BuildRequires:
libatomic_ops*-static*, libatomic_ops-devel
./p/pygrib.git/pygrib.spec:BuildRequires: g2clib*-static*
./p/python-mapnik.git/python-mapnik.spec:BuildRequires: mapnik-devel
mapnik*-static* mapnik-utils
./p/pyosmium.git/pyosmium.spec:BuildRequires: libosmium*-static* >=
%{libosmium_version}
./p/python-assimulo.git/python-assimulo.spec:BuildRequires:
blas*-static*, numpy-f2py, scipy, dos2unix, xorg-x11-server-Xvfb
./p/python-assimulo.git/python-assimulo.spec:BuildRequires:
blas*-static*, python3-numpy-f2py, python3-ipython-console,
python3-scipy
./p/pythonqt.git/pythonqt.spec:BuildRequires: qt5-qttools*-static*
./q/qcad.git/qcad.spec:BuildRequires: qt5-qttools-devel, qt5-qttools*-static*
./q/qemu-sanity-check.git/qemu-sanity-check.spec:BuildRequires: glibc*-static*
./q/qgnomeplatform.git/qgnomeplatform.spec:BuildRequires: qt5-qtbase*-static*
./q/qm-dsp.git/qm-dsp.spec:BuildRequires: kiss-fft*-static*
./q/qm-vamp-plugins.git/qm-vamp-plugins.spec:BuildRequires: kiss-fft*-static*
./q/qm-vamp-plugins.git/qm-vamp-plugins.spec:BuildRequires: qm-dsp*-static*
./q/qt5ct.git/qt5ct.spec:BuildRequires: qt5-qtbase*-static*
./q/qt5-qt3d.git/qt5-qt3d.spec:BuildRequires: qt5-qtbase*-static* >= %{version}
./q/qt5-qtcanvas3d.git/qt5-qtcanvas3d.spec:BuildRequires: qt5-qtbase*-static*
./q/qt5-qtgamepad.git/qt5-qtgamepad.spec:BuildRequires:
qt5-qtbase*-static* >= %{version}
./q/qt5-qtquickcontrols.git/qt5-qtquickcontrols.spec:BuildRequires:
qt5-qtbase*-static* >= %{version}
./q/qt5-qtscript.git/qt5-qtscript.spec:BuildRequires:
qt5-qttools*-static* >= %{version}
./q/qt5-qtstyleplugins.git/qt5-qtstyleplugins.spec:BuildRequires:
qt5-qtbase*-static*
./q/qt5-qttools.git/qt5-qttools.spec:BuildRequires:
qt5-qtbase*-static* >= %{version}
./q/qt5-qttools.git/qt5-qttools.spec:BuildRequires:
qt5-qtdeclarative*-static* >= %{version}
./q/qt5-qtwayland.git/qt5-qtwayland.spec:BuildRequires: qt5-qtbase*-static*
./q/qt5-qtwebengine.git/qt5-qtwebengine.spec:BuildRequires:
qt5-qttools*-static* >= %{version}
./q/qemu.git/qemu.spec:BuildRequires: glibc*-static* pcre*-static*
glib2*-static* zlib*-static*
./r/radvd.git/radvd.spec:BuildRequires: flex*-static*
./r/redhat-lsb.git/redhat-lsb.spec:BuildRequires: glibc*-static*
./r/rhdb-utils.git/rhdb-utils.spec:BuildRequires: postgresql-devel,
postgresql*-static*
./r/rkt.git/rkt.spec:BuildRequires: glibc*-static*
./r/rust.git/rust.spec:BuildRequires: llvm*-static*
./s/saga.git/saga.spec:BuildRequires: e00compr*-static*
./s/scalapack.git/scalapack.spec:BuildRequires: mpich-devel*-static*
./s/scantailor.git/scantailor.spec:BuildRequires: glibc*-static*
./s/SDL2_gfx.git/SDL2_gfx.spec:BuildRequires: SDL2*-static*
./s/secilc.git/secilc.spec:BuildRequires: libsepol*-static* >=
%{libsepolver}, dblatex, flex, xmlto, pandoc
./s/seqan.git/seqan.spec:BuildRequires: libstdc++*-static*
./s/setools.git/setools.spec:BuildRequires: libsepol-devel >=
%{sepol_ver}, libsepol*-static* >= %{sepol_ver}
./s/sim.git/sim.spec:BuildRequires: flex*-static*
./s/simon.git/simon.spec:BuildRequires: flex flex*-static*
./s/snappy-java.git/snappy-java.spec:BuildRequires: libstdc++*-static*
./s/splint.git/splint.spec:BuildRequires: flex flex*-static*
./s/subsurface.git/subsurface.spec:BuildRequires:
libdivecomputer-subsurface*-static*
./s/supermin.git/supermin.spec:BuildRequires: glibc*-static*
./s/surf-geometry.git/surf-geometry.spec:BuildRequires: flex*-static*
./s/sympol.git/sympol.spec:BuildRequires: eigen3*-static*
./t/tcpxtract.git/tcpxtract.spec:BuildRequires: flex*-static*
./t/texstudio.git/texstudio.spec:BuildRequires: qt5-qttools*-static*
./t/thrift.git/thrift.spec:BuildRequires: boost*-static*
./t/thunderbird.git/thunderbird.spec:BuildRequires: nss*-static* >=
%{nss_version}
./u/urdfdom.git/urdfdom.spec:BuildRequires: urdfdom-headers*-static*
./u/usbguard.git/usbguard.spec:BuildRequires: PEGTL*-static*
./u/ustl.git/ustl.spec:BuildRequires: libstdc++*-static*
./w/wgrib2.git/wgrib2.spec:BuildRequires: g2clib*-static*
./w/widelands.git/widelands.spec:BuildRequires: boost*-static* >= 1.47.0
./w/wine-mono.git/wine-mono.spec:BuildRequires: mingw64-winpthreads*-static*
./w/wine-mono.git/wine-mono.spec:BuildRequires: mingw32-winpthreads*-static*
./x/x2goclient.git/x2goclient.spec:BuildRequires: qtbrowserplugin*-static*
./x/xmlindent.git/xmlindent.spec:BuildRequires: flex flex*-static*
./x/xulrunner.git/xulrunner.spec:BuildRequires: nss*-static* >= %{nss_version}
./z/zathura-pdf-mupdf.git/zathura-pdf-mupdf.spec:BuildRequires: mujs*-static*

I'm almost sure that linking against static postgresql client libraries is
wrong and after careful review above will be possible to remove building
and packaging man static subpackages.
Other conclusion is that above grep output is way to shot comare with those
+190 -static subpackages so definitely something like 2/3 of those
subpackages can be removed without any risk.
On above suspiciously is looking for example bison and flex.

Any other comments?

kloczek

[Jan Kratochvil]

Post by Tomasz Kłoczko
./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}

This is a false positive as it is enclosed by:
%if 0%{?_with_testsuite:1}

I have no idea how common it may be but your grep could check %ifs.


Jan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorap

[Jan Kratochvil]

I saw already such tweaks in many Fedora specs %check sections.
IMO such %ifing inside or around %check is incorrect/not needed and can be
removed.
- all possible to use package tests should be by default enabled
- if rpm packager want to speedup generate binary packages avoiding
execution of %check section it is already possible to do this without spec
file %ifing by use *--nocheck* rpmbuild option.

It is really not so simple. :-)

Running GDB testsuite in Koji was crashing the build hosts as they were
running on older RHEL kernels with ptrace bugs. Hopefully they all run recent
enough RHELs now but I did not check (=read /proc/version from *.spec).

But besides that the testsuite from Koji was + would be too unrealiable to use
as GDB testsuite is very sensitive to machine load. And you cannot guarantee
no other rpms get built on the same Koji host as your rpm. So I run the
testsuite only on machines under my control using --with testsuite.

You may say one may completely drop any testsuite runs from the gdb.spec and
run it all only externally from some extra scripts. But that is inconvenient
for me (and Red Hat QA) as we deal with so many GDB releases for many
RH OSes/versions/arches/variants that it is most convenient to keep all the
testing pre-requisites + rules in one gdb.spec for the GDB variant under test.

So probably now is clear that with %ifed BuildRequires (like it is now)
everything would be way harder.

Just include --with testsuite to Fedora Packaging Guidelines instead of new
CheckBuild keyword. I have seen also --with check to be used.


Jan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-

[Tomasz Kłoczko]

(Resending below as looks like I've replied only to Jan)

Post by Jan Kratochvil

Post by Tomasz Kłoczko
OK here is full list of spec files which have glibc-static in
./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local}

%if 0%{?_with_testsuite:1}
I have no idea how common it may be but your grep could check %ifs.

I saw already such tweaks in many Fedora specs %check sections.
IMO such %ifing inside or around %check is incorrect/not needed and can be
removed.
Why? Because:
- all possible to use package tests should be by default enabled
- if rpm packager want to speedup generate binary packages avoiding
execution of %check section it is already possible to do this without spec
file %ifing by use *--nocheck* rpmbuild option.

However IMO still few things are missing in whole %check framework:
- rpm spec file syntax should be extended to add CheckRequires:
dependencies.
- second part missing in this picture is "bcond_with{,out} check" to have
possibility hardcode disable %check if for example package produces 100%
healthy package(s) but test suit is broken and when package will be pushed
to official build systems %check should be disabled.

Of course --nocheck should disable using all CheckRequires dependencies and
--nocheck should change "check" bcond state.

If someone will ask me why CheckBuild dependencies are better than
currently used bconds around some BuildRequires here is my answer.
rpm provides some not well known way to dump all possible informations
about all properties of the spec file.
Just to test this try to execute "*rpmbuild -bp --nodeps --define 'prep
%dump' <foo>.spec*"
Such output is way easier to parse to for example start feeding using those
informations some database to start doing some nasty queries against such
data on a scale of whole distribution.
With separated CheckBuild dependencies it would be possible to produce
exact check list dependencies list in oneliner using above duping technique.
So probably now is clear that with %ifed BuildRequires (like it is now)
everything would be way harder.

Such hooking point to dump spec file parser data could be as well used as
yet another koji regression test unit which will be tracking changes in
spec files between releases/version/archs.

And yet another small idea related to %check.
I know that many Fedora packages can be extended by add %check because
original source trees provides some test suits.
IMO it would be good to identify full list of package spec files without
%check to ask all those packages maintainers to check is it possible to add
%check or confirm that package source tree does not provide test suite.
If rpm will be extended by add std "check" bcond such lack of of test suite
could be marked by add explicit in spec disable use %check even if there is
no %check section.

Just realized that add such std check bcond should be quite easy to
implement by only changing macros provided in rpm-build package.
Probably will try to add this trivial change :)
Team such bcond with --nocheck commandline option would be a bit harder but
add standardised way to disable use by default %check execution will be
trivial ..
If --nocheck is done over popt macro still it may be easy to add it (I need
to check rpm code).

BTW: what is the best Fedora method to preserve such ideas
somewhere/somehow?
Bugzilla?
(I'm still learning Fedora WayOfDoingThings(tm) :) )
kloczek

[Jan Kratochvil]

Post by Tomasz Kłoczko
(Resending below as looks like I've replied only to Jan)

also resending

Post by Tomasz Kłoczko
I saw already such tweaks in many Fedora specs %check sections.
IMO such %ifing inside or around %check is incorrect/not needed and can be
removed.
- all possible to use package tests should be by default enabled
- if rpm packager want to speedup generate binary packages avoiding
execution of %check section it is already possible to do this without spec
file %ifing by use *--nocheck* rpmbuild option.

It is really not so simple. :-)

Running GDB testsuite in Koji was crashing the build hosts as they were
running on older RHEL kernels with ptrace bugs. Hopefully they all run recent
enough RHELs now but I did not check (=read /proc/version from *.spec).

But besides that the testsuite from Koji was + would be too unrealiable to use
as GDB testsuite is very sensitive to machine load. And you cannot guarantee
no other rpms get built on the same Koji host as your rpm. So I run the
testsuite only on machines under my control using --with testsuite.

You may say one may completely drop any testsuite runs from the gdb.spec and
run it all only externally from some extra scripts. But that is inconvenient
for me (and Red Hat QA) as we deal with so many GDB releases for many
RH OSes/versions/arches/variants that it is most convenient to keep all the
testing pre-requisites + rules in one gdb.spec for the GDB variant under test.

Post by Tomasz Kłoczko
So probably now is clear that with %ifed BuildRequires (like it is now)
everything would be way harder.

Just include --with testsuite to Fedora Packaging Guidelines instead of new
CheckBuild keyword. I have seen also --with check to be used.


Jan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe s

[Josh Stone]

./r/rust.git/rust.spec:BuildRequires: llvm-static

This one is conditional, generally disabled. We use it to break rust's
bootstrap dependency when llvm is being rebased to a new soname.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproje

[Kevin Kofler]

Post by Tomasz Kłoczko
BuildRequires: qt5-qtbase*-static*

There are a few small libraries that Qt upstream ships only as static,
because they are not covered by the binary compatibility guarantees:
http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/tree/qt5-qtbase.spec#n874

The main parts of Qt are always linked dynamically, and in fact qt5-qtbase
ships them only as shared libraries. But the Qt maintainers do not want to
attempt shipping shared libraries for those libraries where upstream does
not support it. That is why some packages BuildRequire qt5-qtbase-static.

Post by Tomasz Kłoczko
BuildRequires: qt5-qttools*-static*

Similar situation here, libQt5UiTools.a is only static.

Post by Tomasz Kłoczko
BuildRequires: eigen3*-static*

This is not really a static library, it is a headers-only library. The
reviewers insisted on the package being called eigen3-static rather than the
eigen3-devel name that was used in the past (for eigen-devel, eigen2-devel).
But its "staticness" is really not very different from that of ANY C++
library that contains templates and/or inlines, even shared libraries (such
as Qt). The only difference is that in Eigen's case there is ONLY the
template and inline code.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject.

[Jonathan Wakely]

Post by Tomasz Kłoczko

Post by Jonathan Wakely
There are people who use the static libraries, for their own reasons,
and don't expect support when they do so.

I can only repeat that such people should consider linking own binaries
against uClibc as this implementation is not affected by issue with hidden
loading NSS DSOs which probably make such binaries useless on moving around
against latest fedora/RH7 and RH5.

If you don't move the binaries around you don't have a problem.

You're still assuming you know everybody's use cases.
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproject

[Tomasz Kłoczko]

On 16 March 2017 at 12:20, Jonathan Wakely <***@fedoraproject.org>
wrote:
[..]

Post by Tomasz Kłoczko
I can only repeat that such people should consider linking own binaries

Post by Tomasz Kłoczko
against uClibc as this implementation is not affected by issue with hidden
loading NSS DSOs which probably make such binaries useless on moving around
against latest fedora/RH7 and RH5.

If you don't move the binaries around you don't have a problem.
You're still assuming you know everybody's use cases.

As an argument against what I'm suggesting already in this thread was used
case statically linked binaries in chrooted envs with some old legacy
binaries.
Risk coming from such scenarios is not as a "potentially may happen in
future" but something which is already happening probably +1 time a day
globally.

If statically linked with glibc binaries will be linked on top latest
Fedora and will be used inside suh envs crash by NSS issue is almost
unavoidable because such binary it will be trying to load NSS DSO modules
from old glibc.
Again: such problems will never happen if using in such extreme/unusual
conditions static libc will be allowed but only against uClibc which is not
affected by NSS ABI issues.

And last argument/nail to this NSS issue coffin.
This issue is so well known to glibc developers that they made glibc static
code producing static NSS modules as statically linked modules. Such
support is provided only for two types of NSS methods: files and dns. This
is kind of very minimal NSS support which potentially in all cases of using
statically linked binaries will be possible to use.
*Problem is* that Fedora glibc is not ready to embed such code statically
because current build procedure does not builds static NSS binaries for
files and dns methods. So *none of the Fedora packages provides
libnns_{files,dns}.a* !!!
Other consequence of above: if someone will be even tying to build
statically linked binaries using other methods of mapping like sss or other
it will be not possible to build such binaries because static glibc code is
not prepared to be linked with more than those handful/stub files and dns
NSS methods support.

BTW: during checking that current Fedora glibc static binaries are not
ready even solve those well known scenarios I found that already glibc spec
file is generating glibs-nss-devel subpackage.

S rpm -qpl glibc-nss-devel-2.25.90-1.fc27.x86_64.rpm
/usr/lib64/libnss_compat.so
/usr/lib64/libnss_db.so
/usr/lib64/libnss_dns.so
/usr/lib64/libnss_files.so
/usr/lib64/libnss_hesiod.so
/usr/lib64/libnss_nis.so
/usr/lib64/libnss_nisplus.so

Looks like someone didn't know that those symlinks are not a devel symlinks
and they are installed by am/ac/lt glibc build suit only because it was
easier to use library build/install method.
Will try to create bugzilla ticket to delete those symlinks in %install,
remove glibc-nss-devel and add it to Obsoletes list.

Another subject related to the NSS libc issue is provide fully working
solutions to any future solutions when NSS ABI issue will be hit again ale
on glibc upgrade will be on the system on some with "in the middle state"
when glibc will be due upgrade and part of the upgrade procedure will be
necessary to execute some script finishing such upgrade. There are two
possible solutions:
1) classic like it is already implemented in Solaris where is provided
/sbin/sh which is static binary not affected by NSS ABI issues
2) use rpm embedded lua interpreter to execute bits of such procedures.

BTW point 2). To avoid /bin/sh dependencies IMO it would be good to invest
some time to review existing %post{,un}, %pre{,un} %trigger scripts to
rewrite as much as possible to use lua rpm internal interpreter instead SH.
However I think that provide in Fedora something like /bin/sash (which is
still available on http://members.tip.net.au/~dbell/programs/) may be very
attractive for some docker/minimalistic scenarios. So provide in Fedora
sahs may be kind of OOTB and fully supported better solution than probably
currently used :)
Definitely this minimalistic shell (his static binary on x84_64 has only
~950KB) is very useful in some systems rescue scenarios. It saved my ass
many times in the past. It is perfect as well as main shell interpreter
inside initrd.


So .. one more time: my proposition *is not about cutting off all people
from using statically libc* linked binaries.
One more time: *it is misunderstanding* and this is not what I'm proposing.
Part of my proposition with stop provide glibc-static is to propose
alternative and 100% working solutions but without glibc-static packages.

You can take it as *provide Right(tm) Solutions* of NSS ABI glibc issues to
all average joe-developers which are 99.99% not aware that potentially
they are shooting in own foot (really number of people around the world
aware of those issues is very low/handful).
*In all those rare cases* instead glibc-static *should be used* *uClibc*
(or alternative).

uClibc is actively developed and widely used on many CPU platforms as it is
essential on many embedded platforms so risk that are some issues with this
library is already probably the same as with using glibc.

uClibc is already part of the Fedora distribution and it is* functional
replacement of glibc-static *in scenarios like using embedded/minimalistic
system images, rescue and early system boo system and other similar
scenarios.

So nothing more needs to be done now except provide in Fedora documentation
that because glibc-static has (by its natural internal complexity) some
well known ABI issues Fredora to prevents happen those issues stops
distributing glibc-static and provides as replacement using uClibc static
libc binaries.

One more time: *provide package and allow to end developers use
glibc-static is nothing more than asking for troubles.*

All test suits using full static linking testing be can abandon as static
linking with libc is a bit pointless (as there is nothing special in glibc
static binaries which may expose some linker issues during such tests).
And/or such test suits should be tweaked to use uClibc as well as *only
officially supported method* of using 100% statically linked binaries so
testing such solution on distribution build layer will be provided as well.
In such scenarios uClibc will be additionally tested on Distro layer during
regular builds of some distribution packages.

kloczek

[Tomasz Kłoczko]

Post by Tomasz Kłoczko
BTW: during checking that current Fedora glibc static binaries are not
ready even solve those well known scenarios I found that already glibc spec
file is generating glibs-nss-devel subpackage.
S rpm -qpl glibc-nss-devel-2.25.90-1.fc27.x86_64.rpm
/usr/lib64/libnss_compat.so
/usr/lib64/libnss_db.so
/usr/lib64/libnss_dns.so
/usr/lib64/libnss_files.so
/usr/lib64/libnss_hesiod.so
/usr/lib64/libnss_nis.so
/usr/lib64/libnss_nisplus.so
Looks like someone didn't know that those symlinks are not a devel
symlinks and they are installed by am/ac/lt glibc build suit only because
it was easier to use library build/install method.
Will try to create bugzilla ticket to delete those symlinks in %install,
remove glibc-nss-devel and add it to Obsoletes list.

FTR: above has now opened ticket
https://bugzilla.redhat.com/show_bug.cgi?id=1433451

I've added few more minor cleanups as well and someone may find them
interesting.
Copy of the %changelog entry:

* Thu Mar 16 2017 Tomasz Kłoczko <***@fedoraproject.org> - 2.25.90-2
- remove nss-devel subpackage as libnss_*.so are not to shared libraries
but loadable modules used by libc. These symlinks are not devel resources
- added glibc-nss-devel to main glibc Obsoletes list
- other minor cleanups:
-- remove Group and Buildroot fields (new packaging policy)
-- execute /sbin/ldconfig in %post/%postun of libcrypt and libcrypt-nss
over -p switch causes that those packages will not have added
"Requires(post): /bin/sh" and "Requires(postun): /bin/sh" and they will
straight depends on /sbin/ldconfig
-- removed (as not needed) conditional %%if around subpackages preambles and
%%post/%%postun scripts (%%if around %%files sections are enough)
-- removed %%clean script as rm -rf "$RPM_BUILD_ROOT" removes as well
*.filelist*
and currently default %%clean is executing "rm -rf $RPM_BUILD_ROOT"
-- move all %%post/%%postup under %%install

In ticket is attached proposed patch.

kloczek

[Kevin Kofler]

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

The thing is, proprietary applications statically linking to glibc are
highly likely to be in violation of the LGPL. Or how many proprietary
applications do you know that distribute their object files (and/or their
source code) to allow relinking against a modified glibc?

ucLibc has the same issue, by the way. musl (https://www.musl-libc.org/) is
a more reasonable choice for people who want to ship a statically-linked
proprietary blob. And, unlike glibc, musl is also designed for static
linking.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai

[Tomasz Kłoczko]

Post by Kevin Kofler
The thing is, proprietary applications statically linking to glibc are
highly likely to be in violation of the LGPL. Or how many proprietary
applications do you know that distribute their object files (and/or their
source code) to allow relinking against a modified glibc?

[mode=kidding]
So stop provide glibc-static and redirect those guys to /dev/tree in uClibc
garden may be kind of "solution" how to block (easy way) violating LGPL ..
[/mode]
I have no even murky idea how many proprietary applications may be on such
list.
TBH all proprietary applications binaries which I know are definitely at
least dynamically linked with glibc.
Really some people are .. "curving" such "sculptures" ? =8-o

ucLibc has the same issue, by the way. musl (https://www.musl-libc.org/) is

Post by Kevin Kofler
a more reasonable choice for people who want to ship a statically-linked
proprietary blob. And, unlike glibc, musl is also designed for static
linking.

Hmm .. so probably this behavior was introduced in last few years.
I'm 100% sure that decade ago was possible to produce uClibc based static
binaries not affected by NSS ABI issue.
Maybe it is some uClibc build option allowing disable NSS support (?)
(I really like coding style of uClibc which been telling me that those guys
grinding this code are really caring about every small detail)
Good to know that it is still some alternative which could be considered as
glibc-static replacement.


kloczek

[Kevin Kofler]

Post by Tomasz Kłoczko
[mode=kidding]
So stop provide glibc-static and redirect those guys to /dev/tree in
uClibc garden may be kind of "solution" how to block (easy way) violating
LGPL ..
[/mode]

I'm not kidding, and uClibc is also under the LGPL.

Post by Tomasz Kłoczko

Post by Kevin Kofler
ucLibc has the same issue, by the way. musl (https://www.musl-libc.org/)
is a more reasonable choice for people who want to ship a statically-
linked> proprietary blob. And, unlike glibc, musl is also designed for
static linking.

Hmm .. so probably this behavior was introduced in last few years.
I'm 100% sure that decade ago was possible to produce uClibc based static
binaries not affected by NSS ABI issue.

I am not talking about technical issues (which I think do NOT affect uClibc,
it is designed for static linking more than glibc is), but purely about
licensing.

Kevin Kofler
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@l

[Jonathan Wakely]

Post by Kevin Kofler

Post by Jonathan Wakely
If glibc-static was removed from Fedora and that change propagated to
RHEL I know of companies that might stop being customers of Red Hat.
Being unable to statically link their applications would be a
showstopper for some, and would cause them to move to a different
distro.

The thing is, proprietary applications statically linking to glibc are
highly likely to be in violation of the LGPL.

Not if they don't distribute their binaries outside the company.

Post by Kevin Kofler
Or how many proprietary
applications do you know that distribute their object files (and/or their
source code) to allow relinking against a modified glibc?
ucLibc has the same issue, by the way. musl (https://www.musl-libc.org/) is
a more reasonable choice for people who want to ship a statically-linked
proprietary blob. And, unlike glibc, musl is also designed for static
linking.

I'm not talking about shipping anything.

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedo

[Tomasz Kłoczko]

Post by Richard W.M. Jones
These are very useful for building embedded systems, initramfses,
static linked binaries of large proprietary programs, and any case
where you don't want to depend on the system libraries.

There are still none of the real embedded systems distributions which are
using statically linked binaries lined with glibc libraries.
Fedora is not for embedded systems and using it on even small systems lie
tv box (with +.5GB RAM) binaries with statically linked glibc will be waste
of memory as already some other running processes will be using shared
glibc libraries.
In such use cases it will be better to link such binaries against uClibc or
link some custom binary in busybox tree (both are part of the Fedora).
Those packages does not provides shared libc ABI .. only static libc.a

Glibc libc code as general libs simple is so bloated that using it on
embedded systems as regular libc is pointless (and still is very hard even
with constantly growing system memory of such systems). This is why
projects like OpenWRT/Lede and other are not using glibc.
Reality is that glibc provides some functions which are really hard to find
even single binary which are using them.

You can easily chop probably half of the glibc libc binary and 99.99% of
whole Fedora distribution binaries will be working. Good that each library
is not loaded as whole object into memory (paging) and only by this it does
not hurts to much (hever whole library public symbols jump table must be
fully initialized and loaded into memory so it is some noticeable cost of
it ..).

kloczek

[Przemek Klosowski]

Post by Tomasz Kłoczko
This problem is waaaay bigger than you may be thinking. Above it is
only tip of the iceberg ..
# dnf list | grep -- -static | grep -c x86_64
196

This includes all available packages, but if you look at the actual
usage on an average system, i.e. only static packages that are actually
pulled in by requirements, it is much, much less. It seems that static
packages are primarily available because some package managers perceive
a potential need for static linking; for instance I see many scientific
libraries (HDF, CDF, scalapack, FFTW), and in that case there is a
residual speed effect and the statically linked applications have a
(perhaps no longer deserved) reputation for being more easily distributable.

I checked on my F25 where I pretty much install everything I might ever
need (6400 packages), and there are just 2 static packages:

llvm-static-3.8.1-2.fc25.x86_64
rust-std-static-1.14.0-2.fc25.x86_64

I think you'd have to explicitly load most of them to get up to 196.