Bug 1475501

Summary:	glibc: [RFE] Fix link namespace coordination issues e.g. static vs. dynamic vs. dlmopen.
Product:	[Fedora] Fedora	Reporter:	Carlos O'Donell <codonell>
Component:	glibc	Assignee:	Carlos O'Donell <codonell>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	arjun, codonell, dj, fweimer, jcajka, law, mfabian, pfrankli, siddhesh
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-10-15 13:45:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Carlos O'Donell 2017-07-26 19:31:57 UTC

A statically linked application (the static namespace), and the dynamically loaded libraries (the dynamic namespace), and any dlmopen'd libraries (newly created link namespace), all need to coordinate in some minimal way to avoid some of the following problems:

* Don't double initialize the same global variable if it has a non-default value.
* If threads are loaded, then each of the namespace must be informed of this and act accordingly.
* If a function touches errno, this errno has to be shared across the namespaces, and all other global state variables that need to be shared between the static "namespace" and the dynamic "namespace."

Fixing this is going to be quit a bit of work and it won't get fixed soon. We'll need some kind of collected shared global state we can pass to the new namespace which allows the implementation to behave sensibly.

The conclusion at Red Hat was to continue to investigate the issue upstream, but that statically linked applications would be very very small and not likely to use any of the features which trigger this problem.

Comment 1 Carlos O'Donell 2017-07-26 19:32:30 UTC

*** Bug 1283710 has been marked as a duplicate of this bug. ***

Comment 2 Florian Weimer 2017-07-27 12:13:34 UTC

Your implication that static dlopen and dlmopen face the same problem is incorrect.  Some aspects are similar, the static dlopen problems are simply bugs.  The dlmopen issue is more of a design problem.

Comment 3 Jan Kurik 2017-08-15 07:10:56 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 4 Florian Weimer 2018-01-12 10:22:14 UTC

Upstream deprecates static dlopen in glibc 2.27.

Comment 5 Florian Weimer 2019-10-15 13:45:46 UTC

See comment 2.  I'm going to close this bug as too broad.  Static dlopen issues will be fixed once we do not use static dlopen for NSS and gconv.  dlmopen isuses are quite different, as I said, and it remains to be seen what we can do there.