If Openmotif is installed when emerging Lesstif, Lesstif links to Openmotif's version of libraries, making them completely unusable (read: not working). The problem appears to be that libraries in system directories are preferred over the correct version in the build tree. Note that uil links to both, libXm.so.2 (the corect one from Lesstif) and to libXm.so.3 (from Openmotif, indirectly via libMrm.so.2). # ldd /usr/lib/lesstif-2.1/libDtPrint.so libXm.so.3 => /usr/lib/openmotif-2.2/libXm.so.3 (0x40011000) libXt.so.6 => /usr/lib/libXt.so.6 (0x4010f000) libSM.so.6 => /usr/lib/libSM.so.6 (0x4015c000) libICE.so.6 => /usr/lib/libICE.so.6 (0x40164000) libXp.so.6 => /usr/lib/libXp.so.6 (0x4017a000) libXext.so.6 => /usr/lib/libXext.so.6 (0x40182000) libX11.so.6 => /usr/lib/libX11.so.6 (0x40190000) libc.so.6 => /lib/libc.so.6 (0x402e4000) libdl.so.2 => /lib/libdl.so.2 (0x4040c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) # ldd /usr/lib/lesstif-2.1/libMrm.so libXm.so.3 => /usr/lib/openmotif-2.2/libXm.so.3 (0x4001c000) libXt.so.6 => /usr/lib/libXt.so.6 (0x4011a000) libSM.so.6 => /usr/lib/libSM.so.6 (0x40167000) libICE.so.6 => /usr/lib/libICE.so.6 (0x4016f000) libX11.so.6 => /usr/lib/libX11.so.6 (0x40185000) libc.so.6 => /lib/libc.so.6 (0x402d9000) libdl.so.2 => /lib/libdl.so.2 (0x40401000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) # ldd /usr/lib/lesstif-2.1/libUil.so libXm.so.3 => /usr/lib/openmotif-2.2/libXm.so.3 (0x4001d000) libXt.so.6 => /usr/lib/libXt.so.6 (0x4011b000) libc.so.6 => /lib/libc.so.6 (0x401e1000) libX11.so.6 => /usr/lib/libX11.so.6 (0x40309000) libSM.so.6 => /usr/lib/libSM.so.6 (0x403e3000) libICE.so.6 => /usr/lib/libICE.so.6 (0x403ec000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) libdl.so.2 => /lib/libdl.so.2 (0x40429000) # ldd /usr/lib/lesstif-2.1/uil libMrm.so.2 => /usr/lib/lesstif-2.1/libMrm.so.2 (0x40013000) libXm.so.2 => /usr/lib/lesstif-2.1/libXm.so.2 (0x40026000) libXp.so.6 => /usr/lib/libXp.so.6 (0x40155000) libXext.so.6 => /usr/lib/libXext.so.6 (0x4015d000) libXt.so.6 => /usr/lib/libXt.so.6 (0x4016b000) libSM.so.6 => /usr/lib/libSM.so.6 (0x401b8000) libICE.so.6 => /usr/lib/libICE.so.6 (0x401c0000) libX11.so.6 => /usr/lib/libX11.so.6 (0x401d7000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x402b1000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40306000) libc.so.6 => /lib/libc.so.6 (0x4032a000) libXm.so.3 => /usr/lib/openmotif-2.2/libXm.so.3 (0x40452000) libdl.so.2 => /lib/libdl.so.2 (0x4054f000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40553000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
From emerge openmotif: * This breaks applications linked against libXm.so.2. * You have to rebuild these applications with revdep-rebuild. and library files where put in /usr/lib directly. How did you emerge these packages? I don't use openmotif or lesstif, but I would believe that you normally don't install them both on the same system.
fixed in motif-config-0.5
Those last two comments are contradicting each other. If I can't have motif and lesstif on the same system, what is motif-config for? And even if I could have lesstif only, doesn't change the fact that lesstif's build system searches for libraries in it's destination before it's own built tree, instead of the other way like everything else does. This still causes problems when upgrading. Also, the fix in motif-config-0.5 does not work, sorry: sh# ls /usr/lib/libXm.so.3 /usr/lib/libXm.so.3 sh# emerge -B lesstif [...] sh# ls /usr/lib/libXm.so.3 ls: /usr/lib/libXm.so.3: No such file or directory
Just remerge your lesstif/openmotif versions with motif-config-0.5 installed and this bug is fixed. Stian's comment was completly off topic.
I was already using motif-config-0.5 .. problem is, with regular emerges it tells me * Starting installation of a new motif version. * Note: You can't use any motif app during this process. at the start and * Finishing installation. * Note: You can now use your motif apps again. near the end. That's bad, for it disables regular motif apps when emerging *lesstif*. Now, when doing an "emerge -B lesstif", the second message does not even show up, and consequently, the original state is never restored, motif is disabled permanently. Just think what happens when building binary packages for a larger number of packages .. after motif/lesstif, further building of any motif app fails and requires manual intervention! I'm sure that is not the intended behaviour.
> That's bad, for it disables regular motif apps when emerging *lesstif*. Yeah, but i couldn't find a different solution. > I'm sure that is not the intended behaviour. No, i'm searching for a fix.
Seems to me that motif-config is totally broken. I got not found: Xm.so.3 messages, so: I figured emerge --oneshot openmotif should fix the problem. It emerged motif-config 0.5 and the latest openmotif 2.2.3-r5 but even after env-update and starting a new shell, still the same linker shared library not found error. I tried motif-config, and there were no profiles. I don't think that the "Now you can use motif apps again" message ever showed up. BTW, what directory should I build motif apps against? I was using /usr/include/openmotif-2.2, does motif-config set a centralized motif include directory?
ack! Sorry about the double post, I added myself to CC, and the browser filled in the Comments field automatically.
this is a different problem, please post a complete log of the merge process, what are your emerge options?
the original problem is fixed now, if you still have your problem open another bug
I really hate to say this, *again*, but, it still is not. The same problem with "emerge -B" as described above now has moved to "emerge -K", i.e., motif includes and libs are disabled and never reenabled when installing binary packages.
next try.
not fixed in -r2
it will be fixed in stable when the testing ebuilds go into stable
When will that be?
Re-assign wrt Bug 23545, maintainer retired.
Those motif versions are long stable