|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>|
|Severity:||normal||CC:||bartron, jjk3, lanius|
|Package list:||Runtime testing required:||---|
Description Diether Bürgi 2005-02-21 19:28:57 UTC
Older programs don't start anymore, fail with "error while loading shared libraries: libXm.so.1: cannot open shared object file: No such file or directory"
Comment 1 Heinrich Wendel (RETIRED) 2005-02-22 06:05:31 UTC
please use revdep-rebuild, libXm.so.1 is no longer supported by the lesstif developers
Comment 2 Diether Bürgi 2005-02-23 20:50:35 UTC
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.
Comment 3 Heinrich Wendel (RETIRED) 2005-02-23 22:28:38 UTC
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
Comment 4 Heinrich Wendel (RETIRED) 2005-02-23 22:40:41 UTC
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
Comment 5 Heinrich Wendel (RETIRED) 2005-03-02 10:38:36 UTC
lesstif-0.93.94-r1 is now in portage which installs lesstif-1.2
Comment 6 Diether Bürgi 2005-03-03 15:06:55 UTC
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.
Comment 7 Heinrich Wendel (RETIRED) 2005-03-07 05:39:53 UTC
fixed in recent versions
Comment 8 Diether Bürgi 2005-03-07 20:17:02 UTC
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
Comment 9 Heinrich Wendel (RETIRED) 2005-03-07 22:28:40 UTC
try to run ldconfig
Comment 10 Heinrich Wendel (RETIRED) 2005-03-08 02:40:27 UTC
Comment 11 Martin Flugeldufel 2005-03-09 14:33:45 UTC
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?
Comment 12 bartron 2005-03-09 15:44:18 UTC
Comment 13 bartron 2005-03-09 15:44:18 UTC
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-188.8.131.52 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 ---
Comment 14 Joel Parker 2005-03-09 18:05:02 UTC
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.
Comment 15 Heinrich Wendel (RETIRED) 2005-03-10 05:27:46 UTC
a.) we need motif-config because openmoitf and lesstif conflict b.) here portage (184.108.40.206) does the following: - pkg_prerm (motif-config --uninstall lesstif-1.2) - pkg_postinst (motif-config --install lesstif-1.2)
Comment 16 Heinrich Wendel (RETIRED) 2005-03-10 06:26:17 UTC
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.
Comment 17 Martin Flugeldufel 2005-03-11 19:19:13 UTC
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.
Comment 18 Heinrich Wendel (RETIRED) 2005-03-11 23:06:53 UTC
other distributions do not need the headers and you can only install the libraries in parallel, binaries and man pages are blocking each other.
Comment 19 Martin Flugeldufel 2005-03-12 21:03:52 UTC
??? 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)
Comment 20 Heinrich Wendel (RETIRED) 2005-03-14 05:28:35 UTC
you may read through bug #29388 if you want the reasons for motif-config. the uninstall bug is fixed, i commited a wrong slotmove
Comment 21 Martin Flugeldufel 2005-03-17 14:54:37 UTC
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)
Comment 22 bartron 2005-03-17 17:30:55 UTC
[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]
Comment 23 Martin Flugeldufel 2005-03-26 19:22:57 UTC
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.