| Summary: | recent lesstif fails to install libXm.so.1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Diether Bürgi <waschmaschinenexperte> |
| Component: | [OLD] Library | Assignee: | Heinrich Wendel (RETIRED) <lanius> |
| Status: | VERIFIED TEST-REQUEST | ||
| Severity: | normal | CC: | bartron, jjk3, lanius |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Diether Bürgi
2005-02-21 19:28:57 UTC
please use revdep-rebuild, libXm.so.1 is no longer supported by the lesstif developers Well libXm.so.1 is still supported/provided by other distributions, and since it is needed by closed source applications we use here, I don't think revdep-rebuild is going to do anything. But recent lesstif versions do not ship with libXm.so.1, but we have to use them since they fix important security bugs. If you can come up with a libXm.so.1 version with all security bugs fixed (bug #78483) i'll include it again, until then -> cantfix lesstif has a backport of this security bug: http://ftp.debian.org/debian/pool/main/l/lesstif1-1/lesstif1-1_0.93.94-11.diff.gz will take a look at it later lesstif-0.93.94-r1 is now in portage which installs lesstif-1.2 libXm.so.1 is installed where no program can ever find it. After running "motif-config -s lesstif-1.2" the library appears in /usr/lib, but then libXm.so.3 is gone and other programs stop working. After running "motif-config -s openmotif-2.2" libXm.so.3 is back but libXm.so.1 is gone. There used to be no such problems some months ago. fixed in recent versions Still not fixed: # motif-config -s lesstif-1.2 # ls /usr/lib/libXm.so.1 /usr/lib/libXm.so.1 # ls /usr/lib/libXm.so.3 ls: /usr/lib/libXm.so.3: No such file or directory # motif3-app motif3-app: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory # motif-config -s motif-2.2 # ls /usr/lib/libXm.so.1 ls: /usr/lib/libXm.so.1: No such file or directory # ls /usr/lib/libXm.so.3 /usr/lib/libXm.so.3 # motif1-app motif1-app: error while loading shared libraries: libXm.so.1: cannot open shared object file: No such file or directory using: - motif-config-0.4 - lesstif-0.93.94-r2 - openmotif-2.2.3-r5 try to run ldconfig and/or env-update Same problem here. env-update and ldconfig don't help, but shouldn't emerge take care of that automatically, anyway? Bartron, could you have a look at this, please? Are you both upgrading lesstif/motif from the previous version, by any chance? In that case I can reproduce said behavior here too, however... it looks more like a portage feature to me (using portage-2.0.51.19 here, but I'm almost sure somebody had a similar problem with another package (gcc?) about a year ago, can't find bug # right now though)... What happens is, when upgrading, portage first merges the new version, then executes the new version's `pkg_postinst', which in turn runs `motif-config --install lesstif-1.2' (this creates `/etc/env.d/15lesstif-1.2') Next, portage runs the old version's `pkg_prerm', which runs `motif-config --uninstall lesstif-1.2' (this removes `/etc/env.d/15lesstif-1.2' again) Here's a partial log from upgrading `lesstif-0.93.94-r1' to `lesstif-0.93.94-r2', (relevant lines marked with "=>")... --- begin log --- # emerge \<lesstif-0.94 [snip long list of output] >>> Merging x11-libs/lesstif-0.93.94-r2 to / [snip list of merged files] * /usr/bin/motif-config: Installing Profile: lesstif-1.2 => ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... [ ok ] >>> x11-libs/lesstif-0.93.94-r2 merged. x11-libs/lesstif selected: 0.93.94-r1 protected: 0.93.94-r2 omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging x11-libs/lesstif-0.93.94-r1... No package files given... Grabbing a set. * /usr/bin/motif-config: Uninstalling Profile: lesstif-1.2 => ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [snip list of unmerged files] >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... [ ok ] >>> Regenerating /etc/ld.so.cache... * Caching service dependencies... [ ok ] >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. --- end log --- Why is motif-config needed in the first place? java-config and gcc-config choose between two implementations of the same thing that can't coexist peacefully. Each motif package installs a differently-versioned library, though, so they can install side-by-side naturally. a.) we need motif-config because openmoitf and lesstif conflict b.) here portage (2.0.51.19) does the following: - pkg_prerm (motif-config --uninstall lesstif-1.2) - pkg_postinst (motif-config --install lesstif-1.2) I see the problem now, there is a difference in the order of pkg_prerm and pkg_postinst if you do an upgrade or a reinstall. It is fixed now. Well, not really. motif-config is now handled correctly during upgrades, but now it fails when unmerging. I.e., if lesstif is uninstalled, it is still listed in motif-config -l. If the just unmerged version happens to be the currently active one, symlinks in /usr/bin and /usr/lib are pointing nowhere from now on. (Could somebody please reopen the bug?) I'll have to agree with Joel here, motif-config causes way more trouble than it solves. Not too long ago, Lesstif and Motif used to be able to exist at the same time without motif-config, just as they do on any other Linux distribution around. other distributions do not need the headers and you can only install the libraries in parallel, binaries and man pages are blocking each other. ??? That's simply not true. In RedHat/Fedora Core, for example, you can install Openmotif and Lesstif development packages all at the same time. Am I the only one who thinks motif-config is a solution to a nonexisting problem? What problems does it solve, compared to the problems it caused so far? Could somebody make a list comparing the advantages/disadvantages of motif-config compared to the previous, use-flag based solution? (Btw, the reason I asked to reopen was not because of this, but because motif-config still is not perfect, in it's 0.4 version it fails to properly unregister uninstalled versions) you may read through bug #29388 if you want the reasons for motif-config. the uninstall bug is fixed, i commited a wrong slotmove Unfortunately, it's not. The problem is "is_upgrade" is always true, also when unmerging, and therefore "motif-config --uninstall" does not run on uninstalls. (I'm already familiar with bug 29388, in fact I was involved with some of the testing at the time and if I remember correctly a motif-config like suggestion was dismissed very fast) [err...shouldn't this particular subproblem be discussed elsewhere?] I can't remember anyone suggesting `motif-config' in that time frame exept as a means to switch between the two mwm implementations. As for the rest, one of my design goals of the original implementation was to preserve the used libraries across updates... best described in a short example... 1. a world update offers updates for application A and application B 2. application A originally built against Opemmotif 3. application B originally built against Lesstif 4. world update does not change (2.) and (3.) (which wasn't even entirely possible at that time...a promised portage feature was "persistant use flags" (portage remembers use flags active at install time across updates) which later became `portage.use') Martin, if this is the feature you're missing you may have a point there (I don't know motif-config's specifications myself), but I think a better place to discuss this would be that other bug. [my apologies to the original reporter for the additional noise] Yeah, that would be one of the features that used to be very important to you 1 1/2 years ago. But, seems #81829 is now a duplicate of #29388. I'll try a new one. |
