Summary: | openmotif can't be built when lesstif is installed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Pierre-Henri Jondot <Pierre-Henri.Jondot> |
Component: | Current packages | Assignee: | Heinrich Wendel (RETIRED) <lanius> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | mkennedy, rac |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Pierre-Henri Jondot
2003-09-13 23:48:06 UTC
openmotif-2.2.2-r2 fixes that, however... Since openmotif-2.2's shared libraries use a different major version number (libs end in `.so.3'), you will have to recompile all package that use Motif. Openmotif-2.1 and lesstif both install the same version of their libraries (`.so.2') and are supposed to be binary compatible, but I'd recommend recompiling all Motif programs as well when switching between them (or expect some random crashes). closing this bug -- bartron hop onto irc and /msg me when you have a chance please re-opening for further examination p-h, a couple of things: I'm not able to reproduce this: I compiled openmotif with lesstif already installed, on a few occasions, and the latest today; also, it seemed as though Bartron reasoned something about it. have you been able to verify that openmotif compiles ok with no lesstif installed? As concerns openmotif-2.2.2-r1, yes it does build fine on my system having previously unmerged lesstif. I have not checked yet if openmotif-2.2.2-r2 (~x86) builds fine against lesstif-0.93.40 as suggests bartron or not. The fact is I solved my problem by editing emacs ebuild by hand and getting rid of the openmotif dependancy, it then built fine and emacs just works fine too. The lesstif library did just suit emacs as well as the openmotif one I suppose. So, in my opinion, I suppose it would be a good thing to replace the lesstif or openmotif dependancy by a virtual/motif one whenever one can be used as well as the other, which it is, I guess, the most often if not always... Of course, that means testing... If some specific packages now specifying openmotif as a dependancy need to be tested, my cpu has some cycles left and can do some. Just tell me which ones. [Note to self: don't go online at this late hour... Comment #1 was written assuming that -r2 has been unmasked some time ago...my bad...] The problem here is that 2.2's original autoconf build makes gcc look for include files in the wrong order in two of its subdirectories, picking up headers in `/usr/X11R6/include' if they exist (causing trouble if they belong to a different Motif); this is what -r2 fixes. The change from the openmotif-2.2.2-r1 ebuild to the -r2 one should indeed allow it to build. But then if the two libraries provided by lesstif and openmotif are binary incompatible, then we might have to reemerge every package depending on motif as suggests bartron. Then assuming (I have no idea if such packages exist and hope not) a package needs lesstif and won't build against openmotif, what will happen if, and I suppose it just does that, the emerging of openmotif replaced all the lesstif header's files with its own ? As for the lesstif dependancy for opera, this is not a problem of course as it is binary and as lesstif and openmotif libraries are not the same version In resume, but it has to be investigated, my guess is that : - lesstif or a previous version of openmotif is necessary to offer binary compatibility with opera (or I should say some plugins to opera) and perhaps others - and I would suppose openmotif-2.2.2 is preferable (?) for the building of source packages but if this is the case, we should prevent a later emerging of lesstif to replace openmotif headers, and in the case where openmotif-2.2.2 got emerged after lesstif, reeemerge all source packages depending on motif... - and if we are very lucky, lesstif and openmotif are never both needed at the same time... emacs people, looks like emacs dep can be virtual/motif [moved the second issue, including some first ideas, to a new bug (bug #29388)] *** This bug has been marked as a duplicate of 29388 *** |