/etc/ld.so.conf is modified and auto-generated by env-update to the effect that one musn't modify it. It seems the idea is that env-update generates an ld.so.conf which automatically coincides with the respective environment by extracting the respective variables. I don't think this should be done, particularly since ld.so is configured through ld.so.conf.d anyway, which is not accounted for by env-update. Therefore it might be nicer and cleaner if the functionality is stripped from env-update so that ld.so can be configured in normal way.
It has been a standard practice for Gentoo packages to install LDPATH settings in /etc/env.d files, for use by env-update to generate /etc/ld.so.conf. Also, eselect has a module that generates /etc/ld.so.conf in a compatible way: https://gitweb.gentoo.org/proj/eselect.git/tree/modules/env.eselect
I think these are two distinct methods to affect ld.so behaviour: Either by the environment or by configuration in ld.so.conf. I also think it is customary to use configuration files for primary configuration and environment variables for overrides, this agrees with the precedence used by ld.so. If packages attempt to configure ld.so by placing their stuff in the environment, I think choosing that method over the configuration file is a rather unfortunate one, but at least it's a consistent choice for one of these two methods. It doesn't require ld.conf.so to be regenerated from the environment, though. I don't see any constraint for "compatibility" there. The two methods (env and config) are deliberately designed such that they may disagree. Hence, although I think it would be nicer if packages used the config-method, there seems to be no need to change any depending packages. Just Gentoo should perhaps choose to decouple the two methods as originally intended for by ld.so.
I'm afraid I don't understand the problem and the change being proposed. Today /etc/ld.so.conf is used by ldconfig to build a ld.so.cache to allow executables to load libraries in non-standard location without a load-time performance penalty: cache resolves filename to absolute path. To do that ld.so.conf needs to be populated. It is done via LDPATH->env-update->ldconfig pipeline described by Zac. Question time: 1. Is there a practical problem that needs a change in how ld.so.conf maintained in Gentoo? Examples are: broken software, additional complexity in managing the system. 2. What is your alternative proposal?
(In reply to Sergei Trofimovich from comment #3) > 1. Is there a practical problem that needs a change in how ld.so.conf > maintained in Gentoo? Examples are: broken software, additional complexity > in managing the system. There is no practical problem other than perhaps a bit of unnecessary complexity and in a way "going against" what is intended by ld.so's configuration semantics. That is, what is traditionally expected from how configuration and environment variables work together and that ld.so.conf be editable. > 2. What is your alternative proposal? As far as env-update and eselect (as Zac pointed out) are concerned: Have env-update (or any other tool, for that matter) not interfere with or modify /etc/ld.so.conf. If any files in env.d/ defined LD* search paths, handle those generically like any other env variable. Consequently, env-update should also not invoke ldconfig (or rather, it would no longer make any sense). As far as packages which install libraries in non-standard places and want to modify the search path (for what it's worth, I think this poses a somewhat strange premise in the first place) are concerned: They may keep modifying env.d (rather than, preferably, ld.so.conf.d), no change is required for them.
Addition: I suppose having env-update invoke ldconfig to regenerate ld.so.cache might just be kept for simplicity for people who are used to just running env-update rather than ldconfig themselves.
(In reply to Cedric Sodhi from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > 1. Is there a practical problem that needs a change in how ld.so.conf > > maintained in Gentoo? Examples are: broken software, additional complexity > > in managing the system. > There is no practical problem Aha. Then the bug is a theoretical design question. It makes it a bit harder to identify something as a problem/deficiency to fix it. > other than perhaps a bit of unnecessary > complexity and in a way "going against" what is intended by ld.so's > configuration semantics. To talk about semantics we need to define the meaning of ld.so.conf/ld.so.cache and operations on them. Operations look slightly different on different systems (see uclibc-ng example). > That is, what is traditionally expected from how > configuration and environment variables work together and that ld.so.conf be > editable. What environment variables working together (together with ld.so.conf?) you are talking about here specifically? > > 2. What is your alternative proposal? > > As far as env-update and eselect (as Zac pointed out) are concerned: Have > env-update (or any other tool, for that matter) not interfere with or modify > /etc/ld.so.conf. If any files in env.d/ defined LD* search paths, handle > those generically like any other env variable. Consequently, env-update > should also not invoke ldconfig (or rather, it would no longer make any > sense). I still don't see a concrete proposal. 1. What packages (or portage?) are supposed to do instead of setting LDPATH= and assuming timely propagation of updates to ld.so.cache (or equivalent)? 2. And what is supposed to perform that propagation? I assume "generic handling" above means adding LDPATH to /etc/profile.env and exporting it instead of assembling ld.so.conf for further ldconfig run. > As far as packages which install libraries in non-standard places and want > to modify the search path (for what it's worth, I think this poses a > somewhat strange premise in the first place) are concerned: They may keep > modifying env.d (rather than, preferably, ld.so.conf.d), no change is > required for them. 'ld.so.conf.d' is not a very portable interface. For example on uclibc/uclibc-ng-based systems ld.so.conf has to contain all the entries [1]. This makes it tedious to implement removal of entries if you have to assume some entries (including one to be removed) were added manually. Instead of having parse->modify->write Gentoo does generate->write and uses LDPATH as such an API. On Gentoo glibc system you can use ld.so.conf.d/ enries yourself if you do not want to use LDPATH mechanism for your use case. [1]: https://github.com/kraj/uclibc-ng/blob/e912bb06c9bf22f2466d647b78ae60142bd13211/utils/ldconfig.c#L559 Here get_extpath() implements extraction of all known library paths.
(In reply to Sergei Trofimovich from comment #6) > What environment variables working together (together with ld.so.conf?) you > are talking about here specifically? Generally what is described in ld.so(8) under DESCRIPTION, e.g. LD_LIBRARY_PATH and ld.so.conf. > I still don't see a concrete proposal. > 1. What packages (or portage?) are supposed to do instead of setting > LDPATH= and assuming timely propagation of updates to ld.so.cache (or > equivalent)? Other libc implementations aside, they should either write entries into ld.so.conf.d/ or modify LD_LIBRARY_PATH. Or any other means described in ld.so(8), really. > 2. And what is supposed to perform that propagation? Depending on which method is chosen, this would be done by `env-update` or `ldconfig` etc *if* *additional* propagation is required and, for example, the package doesn't install files into ld.so.conf.d/ and run `ldconfig` by itself. > I assume "generic handling" above means adding LDPATH to /etc/profile.env > and exporting it instead of assembling ld.so.conf for further ldconfig run. Yes, although, if I understand correctly, LDPATH is a Gentoo specific definition which by itsself wouldn't have any effect. > 'ld.so.conf.d' is not a very portable interface. For example on > uclibc/uclibc-ng-based systems ld.so.conf has to contain all the entries > [1]. This makes it tedious to implement removal of entries if you have to > assume some entries (including one to be removed) were added manually. > Instead of having parse->modify->write Gentoo does generate->write and uses > LDPATH as such an API. I admit, I did not have other libc implementations in mind when I discussed this. I'm really unsure as to how far Gentoo (and all ebuilds!) can be expected to accommodate other libcs, for instance something as "unusual" or minimal as uclibc-ng. Personally, I think, principally, we have to draw a line somewhere and might expect that if a libc crosses that line, they will have to fix things up on their side. Writing an ebuild, I already would have unsuspectingly tripped over uclibc's behaviour under the current circumstances. Having configured my system using the existing ld.conf.d/, I'd have unsuspectingly tripped over it when migrating to uclibc. I'm not necessarily saying that not-supporting ld.so.conf.d/ would be crossing that line, but I don't find it that much of a problem, either. As it is, every install entails a "propagation" like you call it. So that propagation may aswell focus on generating ld.so.conf from ld.so.conf.d/ (instead of from extracing environment variables from env.d/) in those cases where the libc does not account for it. It would still mean that ld.so.conf is autogenerated and not editable as intended by glibc's ld.so, but that is... 1. ...in fact to be expected, as it's no longer glibc. 2. ...still taking environment variables and their extracting out of the equation and thus makes things simpler.
[eselect maintainer] As far as env.eselect is concerned, it has an option that will prevent it from touching ld.so.conf (and from running ldconfig): $ eselect env help Manage environment variables set in /etc/env.d/ Usage: eselect env <action> <options> Standard actions: help Display help text usage Display usage information version Display version information Extra actions: update <noldconfig> Collect environment variables from all scripts in /etc/env.d/ noldconfig Do not alter the ld.so cache or configuration. Apart from this, does the current behaviour cause any breakage, or does it interfere with any concrete workflow? If not, eselect will be out of here.
Aren't `eselect env update` and `env-update` the exact same thing? In both cases, the suggested change would probably involve making "noldconfig" respectively "--no-ldconfig" the default behaviour.
Your comment made me realize, though, why Sergei is missing a "concrete proposal" from me. There is indeed hardly any change at all, other than changing the "standard workflow" to modify LD search paths from "using the extraction of environment variables and, secondarily, modifying ld.conf.so.d" to only and primarily "modifying ld.conf.so.d".
Eventually, if you think the complications with other libcs warrant this slight inconsistency with glibc (and perhaps other libcs with coinciding configuration semantics), I have no objection against RESOLVED INVALID. It's just my personal opinion (backed by some debate on IRC), that we should pick a standard baseline (glibc) and make that entirely clean (instead of compromising to make it "equally fair or inconsistent" for every situation). Systems which deviate from that baseline could then be explicitly responsible to account for that, which should always be possible.
(In reply to Cedric Sodhi from comment #9) > Aren't `eselect env update` and `env-update` the exact same thing? eselect has both: It uses portage's env-update if it is available, otherwise (i.e., with other package managers) it falls back to its own implementation. > In both cases, the suggested change would probably involve making > "noldconfig" respectively "--no-ldconfig" the default behaviour. At least as far as eselect is concerned, I don't see sufficient reason for flipping the default. This is the first bug report that I see about the issue, and it seems rather academic since it comes without any evidence of concrete breakage.
