Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
[continuation of Bug #28670. Bug #28670 originally was about Openmotif not compiling with Lesstif already installed, but also scratched another problem, different packages hard- depend on either Motif or Lesstif, and may pull in the other toolkit with some undesired side-effects] The ultimate solution of course would be to only allow one of them which blocks the other one, but... * the latest version of Openmotif in portage is not binary-compatible with the latest version of Lesstiff. Programs linked against Lesstif will not run with Openmotif and vice versa. * Lesstif is Motif-2.1 (altough it also installs 2.0 and 1.2 libraries) * Openmotif(-2.2.2) is Motif-2.2 (but uses soname=lib*.so.3 in its shared libraries). Technically, it *could* install into its own slot, but since it offers no (usable) new functionality, and is incompatible with commercial, binary-only packages, the cleanest (although not necessarily the easiest) solution imho would be to downgrade to 2.1.30. (see <http://www.motifdeveloper.com/tips/Motif22Review.pdf>) * Lesstif's 2.1 libraries are (supposed to be--needs some testing of course) binary compatible with Motif-2.1, as well as existing closed-source programs. Idially, packages that (r)depend on virtual/motif would pull in the virtual's default or use whatever is currently installed and just work (only programs that should need openmotif are those that use mrm/uil functionality, but those are very rare). What I was thinking of is... 1. Clean up the Openmotif-2.1.30 ebuild a bit * currently it doesn't install manpages and fights with xfree over a couple of files. 2. Have Lesstif provide the exact same files * remove 2.0 and 1.2 libraries, they triple compile time and are not really used. - Source packages will always link against 2.1 libs. - There's no point having 2.0 and 2.1 libs in the same dir as they share the same soname and ldconfig will bend the soname-level symlink to the higher version (2.1) each time it runs. * 1.2 libs could possibly go in a different package, there's still one program that uses them: netscape-dyn-motif in Netscape-4.x 3. Turn Openmotif-2.2.2 into a small package (lets call it 2.2.2-r3) that does not provide `virtual/motif' and that only installs its shared libraries (no manpages, no static libs, no headers, no programs -- shared libs can coexist because of different versions (SLOT="2.2" or different pkg name?)) 4. (the real ugly part) * hard-mask 2.2.2 .. 2.2.2-r2 * have 2.1.30-r2 pull in 2.2.2-r3 if it detects 2.2.2 is currently merged (((I know this is against serveral policies, and I didn't really say that, but it's the only way I can think of to automate the whole thing without breaking installed programs (ebuild-based or not) that are linked against 2.2.2))) [[still working on that last step]] As of Sep 20, these are the ebuilds that need testing: package (r)depends on ------------------------------------------------------------ 1 app-editors/emacs >=x11-libs/openmotif-2.1.30 2 app-editors/gvim virtual/motif 3 app-editors/nedit virtual/motif 4 app-editors/xemacs >=x11-libs/openmotif-2.1.30 5 app-emulation/glukala virtual/motif 6 app-misc/grass virtual/motif 7 app-misc/xlockmore virtual/motif 8 app-misc/xplore virtual/motif 9 app-sci/electric virtual/motif 10 app-sci/ncbi-tools >=x11-libs-openmotif-2.2.2 11 app-sci/xephem x11-libs/openmotif 12 app-text/mgv virtual/motif 13 app-text/xpdf virtual/motif 14 dev-db/sqsh virtual/motif 15 dev-java/compaq-jdk >=x11-libs/openmotif-2.1.30-r1 16 dev-java/compaq-jre >=x11-libs/openmotif-2.1.30-r1 17 dev-java/sun-j2sdk-1.4.0-r3 !x11-libs/lesstif !x11-libs/openmotif (???) 18 dev-libs/mpatrol virtual/motif 19 dev-util/ddd virtual/motif 20 kde-base/kdebase virtual/motif 21 kde-base/kdemultimedia virtual/motif 22 media-gfx/grace virtual/motif 23 media-radio/xastir virtual/motif 24 media-sound/snd x11-libs/openmotif 25 media-sound/timidity++ >=x11-libs/openmotif-2.1 26 media-tv/xawtv virtual/motif 27 net-print/mtink virtual/motif 28 net-www/amaya virtual/motif 29 net-www/opera-7.11-r2 >=x11-libs/lesstif-0.93.40 30 net-www/opera-7.20_beta7 >=x11-libs/lesstif-0.93.40 31 net-www/opera-7.20_beta9 >=x11-libs/lesstif-0.93.40 32 x11-libs/ViewKlass ~ virtual/motif 33 x11-misc/xcalendar >=x11-libs/openmotif-2.2.1 34 x11-misc/xcb virtual/motif 35 x11-misc/xmbdfed >=x11-libs/openmotif-2.1.30 36 x11-misc/xscreensaver virtual/motif 37 x11-terms/rxvt x11-libs/openmotif 38 x11-wm/evilwm virtual/motif 39 x11-wm/lwm virtual/motif
Created an attachment (id=18168) [details] openmotif-2.1.30-r99.ebuild revised openmotif-2.1, in case someone wants to test if opera works with it.
Created an attachment (id=18169) [details] files/openmotif-2.1.30-imake-tmpdir.patch required patch
Interesting reading (about openmotif-2.2.2)... A few comments : I didn't wait for the revised openmotif-2.1.30 to unmerge lesstif and emerge openmotif-2.1.30 instead. (Well, perhaps I should have...) I wanted to test how a emacs built against lesstif would react to it... no crash of any sort, just a laconic message indicating the libraries provided by lesstif-0.93.40 and openmotif-2.1.30 are not binary compatible, as they should... This message is : emacs: Symbol `_XmStrings' has different size in shared object, consider re-linking apart from this message though, it looks like emacs is working fine. As for opera, I realize I never got flash plugin to work properly, either with lesstif or openmotif... Strangely enough, flash plugin do work when opera is executed by root, but then, with openmotif, the same message about `_XmStrings` appears... Would it mean the operamotifwrapper has been linked against lesstif library ? (the website says it has been tested with openmotif-2.1.30 instead...) As for the impossibility to view flash pages as a regular user, I did check permissions in the plugin directory of opera... No clue. As concerns the revised openmotif-2.1.30 ebuild, you did well to add a NOINSTBINARY variable... but I suppose you should include xmkmf in the list. Pierre-Henri. (who'll try to remember not to unmerge openmotif in the near future...)
Thanks for the quick test, I'll attach a new version with xmkmf added. The second problem, however, looks like a first blocker... `_XmStrings' is a variable in libXm with all the internal strings ( {Widget,Gadget,Resource}{names,Classes} ) strung together into one huge string so they can be imported via a single symbol. (there are #define's that expand to something like `&_XmStrings[ofs]') The offset is determinded by the toolkit used at compile-time, and would better match the offset at runtime. If `_XmString' were only missing some strings at the end that are never used (otherwise this would be caught at build-time when building with Lesstif), there wouldn't be a problem, but... --- /* gcc -I/usr/X11R6/include -L/usr/X11R6/lib -lXm -o xmstrtest xmstrtest.c */ #include <stdio.h> #include <Xm/Xm.h> int main() { printf("\'%s\'\n", XmNtearOffTitle); return 0; } --- $ ./xmstrtest 'tearOffTitle' $ LD_LIBRARY_PATH=/path/to/lesstif-libs ./xmstrtest 'rOffTitle' --- [a work-around would be to compile all motif apps with `XMSTRINGDEFINES' defined] Raker, Lanius, CC'ing you here. From Changelog you seem to be the last two ebuild maintainers, could one of you report this upstream? This is actually a rather simple patch, but having looked at Motif sources, I can't really contribute to Lesstif myself. [testing previous Lesstif-versions during the next days]
Created an attachment (id=18281) [details] openmotif-2.1.30-r99.ebuild remaining conflicts with xfree removed lesstif block added
Created an attachment (id=18283) [details] lesstif-0.93.40-r99.ebuild first attemt of a lesstif ebuild that resembles openmotif layout as close as possible
i'll take a deeper look into it later this week, but seems good on the first view :)
and please bump lesstif to the latest version ;)
where can i find this netscape-dyn-motif app?
[sorry, forgot to explain that] -r99 just has been chosen to avoid pollution of the namespace... being KEYWORDS='-*', it should still downgrade painlessly if emerged accidentally. The problems I still see are: * even after re-libtoolize'ing, lesstif still looks for libraries in `/usr/X11R6/lib' first instead of `$D/usr/X11R6/lib' in some of its subdirs (shouldn't hurt anything as it's only for resolving symbols, but still looks ugly...) * I still didn't get to check if virtuals can default to a particular slot... my original vision was to Motif-2.2 libs and Lesstif/Motif-2.1 being able to coexist...Motif-2.2 libs in SLOT="2.2" and Motif-2.1 and Lesstif in SLOT="2.1", blocking each other. In that case, Lesstif would have to block `x11-libs/openmotif-2.1' only, and `virtual/motif' needs to default to `x11-libs/openmotif-2.1'. The dynamic [shared]-motif netscape binaries are in net-www/netscape-communicator and net-www/netscape-navigator. [not installed if using the ebuilds though]
re: the _XmStrings issue... Went to Lesstif's cvs, and it seems this is work in progress. The last comment on `lib/Xm-2.1/XmStrDefs.c' states this file (and the corresponding header) is a copy from 2.0 for now and will be changed later (unfortunately hasn't changed since 2000/11/15). Looks like a real blocker, because without that sorted out, Lesstif and Motif are not interchangable without recompiling binaries that link to `libXm' IF they reference any string past `XmRTopItemPosition'.
maybe you should open a bug on http://sourceforge.net/tracker/?atid=108596&group_id=8596 ?
[reported on Sep 27, 2003, no response yet though] As a temporary solution, I'd say let's pad `_XmStrings' to the same size as motif to at least get rid of that ld.so warning. That way, most packages that don't require some of the 2.x functionality (namely XmContainer, XmNotebook and XmSpinBox) will work with both, regardless if they're compiled against Motif or Lesstif headers. As for the rest...they'll have to depend on `x11-libs/openmotif' for now... It's not totally error proof -- a user may unmerge openmotif and install Lesstif with one of these packages already installed -- but the only alternative would be to remove Lesstif from virtual/motif (don't really like that idea, although it would make things a lot easier, documentation and maintenance wise). Next (and hopefully last) obstacle is opera... With the above approach, there can't be anything that depends on `x11-libs/lesstif' directly, just via `virtual/motif'. An elf-header analysis shows that in the (latest?) beta, `operamotifwrapper' is most likely compiled with lesstif [in opera 7.11 it appears to be motif 2.1 though...], however, these newer versions also have a `operamotifwrapper-3' which is built with motif 2.2. What needs to be tested is, does `operamotifwrapper' included in newer operas work with motif 2.1.
Unfortunately, there seem to be more (binary) incompatibilities in Lesstif's 2.1 libXm than I hoped. Next problem is a size difference in XmLabel's instance record. Usually, these structures aren't accessed by applications directly, only if they implement their own Widgets that subclass the class in question, but... One rather important program that does exactly that is `ddd' (to implement its "disabled 3D look").
so are there any packages that work with lesstif, but not with openmotif?
Well... there shouldn't be any *source* packages that don't work (or if there are, there's always a way to make them :). Only case when there will be a problem is if a program does not use the same *tif at runtime than the one it was built with, IFF it either accesses internal structures that differ in layout between the two implementations (or maybe versions), or accesses a part of _XmStrings from a certain offset onwards (known programs that don't do that are `nedit', `xpdf' and `mgv', one that does it is `ddd'). To return to the original question...yes, `operamotifwrapper' in newer `opera' betas appears to be built with Lesstif, judging by some hints in its dynamic symbol table and the `_XmStrings' size mismatch when running with openmotif-2.1 (Comment #3). Unfortunately, the exact version used, and if it uses features that break with a different libXm...only Opera Software ASA can say that for sure...
[the more I think of it, there seems to be no easy way to stick with `virtual/motif'] Even though this is an even more radical change, here's a different idea how to solve to the whole problem without limiting the users choices... (1) drop `virtual/motif' (2) Openmotif-2.1 (libs and headers) goes into `/usr/X11R6', as before, slotted "2.1" (without the virtual that always pulls in the highest available version/slot, slotting and depending on a lower version is now possible) (3) Openmotif-2.2 (libs only) goes into `/usr/X11R6', slotted "2.2" (to support existing binaries built with 2.2 or possible binary-only packages that need it) (4) put Lesstif (1.2 headers and libs) into its own subdir (`/usr/LessTif' or `/usr/X11R6/LessTif') and link the libraries (minus the versionless link) to a directory in ld.so's search path. [excludes binaries in $lesstif-dir/bin yet--still thinking about the best way to handle them] (5) add a new USE flag, "lesstif" in autoconf based builds the only required change is adding `--with-motif-includes=$lesstif-dir/include' and `--with-motif-libraries=$lesstif-dir/lib' to the configure line if "lesstif" is in `USE'. (6) seems very much like a kludge to me, but if opera turns out to not work correctly with motif's libXm, make a wrapper around the wrapper that points LD_LIBRARY_PATH to a Lesstif libXm-2.1 provided by its own ebuild. [I'll prepare one or two sample ebuilds...after doing some more testing]
Created an attachment (id=18704) [details] openmotif-2.1.30-r99.ebuild almost unchanged, could be final version * removed virtual/motif * removed block on lesstif * added slot 2.1
Created an attachment (id=18705) [details] lesstif-0.93.40-r99.ebuild this one installs into its own tree, `/usr/X11R6/LessTif', and can co-exist with openmotif. * virtual/motif removed * block on openmotif removed * programs in bin and man pages not handled yet 0.93.40 may not be the optimal version though... nedit-5.4RC1 adds a version check -- the last version that nedit considers `known-good' is 0.93.32
Created an attachment (id=18707) [details] mgv-3.1.5-r99.ebuild simple autoconf-based ebuild that makes use of the above -- with "lesstif" in USE it will depend on and build with Lesstif, if not, it will use openmotif instead.
Created an attachment (id=18708) [details] nedit-5.4_rc1-r99.ebuild example non-autoconf based ebuild...doesn't apply the 5.3 gentoo patches yet and required a slight hack to build with Lesstif-0.93.40 without user interaction.
*** Bug 28670 has been marked as a duplicate of this bug. ***
my suggestion would be to have the following: lesstif provides virtual/motif-2.1 and is slottet 2.1 openmotif-2.1 provides virtual/motif-2.1 and is slottet 2.1 openmotif-2.2 provides vitual/motif-2.2 is slottet 2.2
all three versions should be installable at once, but packages should preferable depend on virtual/motif-2.1
If it only where that easy -- if openmotif and lesstif both provide 2.1 libraries, then they can't be installed at the same time, and switching between them requires recompiling/linking of some programs. If Lesstif installs only its Motif-1.2 parts, they are completely different things that can coexist, but there's no real point for them to providing any virtuals anymore. Even today, very few applications actually use Motif-2.x features, and even if they do, they come with their own implementation of the missing 1.2 features in most cases. As for openmotif-2.2... that's a difficult issue. Basically, for a *complete* installation, it would have to go into its own tree as well (to avoid conflicts with 2.1's headers), and would require a second use flag and modifications to all ebuilds that would want to use it. But then, there's absolutely no benefit using it (it's only licensed on free operating systems; any program that uses 2.2 features (despite OSF's other concerns) would not be portable to commercial OSs). Only purpose right now (sorry, ICS) would be some compatibility, libs-only ebuild to allow applications requiring libXm.so.3 to run. (slotting is so emerging 2.2 won't unemerge 2.1).
is there no way to install lesstif and openmotif 2.1 at the same time?
Well, n...yes, but only when getting rid of `virtual/motif' (cleanest solution to me seems to go with Comment #17 :). That way, the decision of whether a program links to Lesstif (libXm.so.1) or Openmotif-2.1 (libXm.so.2) is made at build time, similar to the way some ebuilds handle Xaw vs. Xaw3d. The only drawback is that programs that specifically require 2.1 functionality can't be built with Lesstif, but on the other hand, Lesstif's implementation of 2.1 features seems to be a bit less tested/finished than their 1.2 counterparts anyways. [[an alternative could be to install Lesstif in 2.1 mode and link programs with `-rpath $lesstif-dir/lib' or install these programs under a different name and wrap them in a small script that sets LD_LIBRARY_PATH (again, depending on a USE flag)... Problem I see here is that both versions will ask for the same library at runtime (libXm.so.2), and if they don't find it in either rpath or LD_LIBRARY_PATH (i.e, a user builds a package with Lesstif and later uninstalls Lesstif and installs openmotif), they will pick up the wrong library <=> expect some obscure bug reports]] From the long list above, packages that definitely work with Lesstif in 1.2 mode without visible/functional differences are: * app-editors/nedit * app-text/mgv * app-text/xpdf * dev-util/ddd * x11-misc/xcalendar A package that does require 2.x is `xplore', but that one doesn't work that well with Lesstif anyway (combobox geometry problem).
*** Bug 30805 has been marked as a duplicate of this bug. ***
*** Bug 30804 has been marked as a duplicate of this bug. ***
we can install lesstif and openmotif at the same time, if we install lesstif in /usr and openmotif in /usr/X11R6
that's also the way debian does it
sounds good to me, any chance to see this in portage soon? what I still don't get is why opera needs lesstiff in the first place, works great with motif here.
I just commited openmotif-2.1.30-r2.ebuild, openmotif-2.2.2-r3.ebuild and lesstif-0.93.91. They are hard-masked for now, can you please take a look at them, barton.
> sounds good to me ...or maybe not; lesstif does not overwrite files anymore, but now nedit ALWAYS thinks it is running with lesstif, but thinks it was compiled with motif, according to the version window. This seems to be solved by removing -I/usr/X11R6/include in the makefile, but we can't remove -L/usr/X11R6/lib because it needs other libraries from there too.
Sorry, major thinking error; and I didn't read the first part; too drunk. This is way to LONG!! Still have to tell programs with what they should run. To compile only 1.2 motif as suggested above looks too debian for my taste! Maybe its esiest to just to add -lesstif to the library names.
[???] Sorry, but I can't see how installing in `/usr' in *2.1* mode is any different from what lesstif-0.94.36 has been doing. First problem, there will be two different copies of lib{Xm,Mrm,uil}.so.2 in two different places, both reachable but only one can win. Second problem, there will be two sets of development files, also both reachable by default...since all Motif programs need other X libraries as well, they definitely need `-L/usr/X11R6/lib', and configure scripts may or may not add `-I/usr/X11R6/include' (X11 includes are already reachable via `/usr/include/X11'). [/???] Debian gets around this because they can (and usually do) split their packages into runtime and development parts and installs lesstif in 1.2 mode... which means the runtime parts can coexist with each other (even if they would have been in the same $prefix), but the -dev and -bin parts do not.
i think we should discuss that on irc, try to catch me on freenode.net
[that's what I've been trying for more than two weeks]
[the current plan is to put lesstif and openmotif-2.2 in their own, isolated trees and symlink the files needed at runtime from standard locations] That way, all existing ebuilds will work without changes if their dependencies are updated to "<x11-libs/openmotif-2.2". Ebuilds that also support lesstif (everything that does not depend on Motif-2.1 functionality) need to depend on "<x11-libs/openmotif-2.2" OR "x11-libs/lesstif" and add `-I$lesstifdir/include' and `-L$lesstifdir/lib' to their compiler and linker options if lesstif is used. Opera-7.x is the only program that needs ">=openmotif-2.2". [`$lesstifdir' should probably defined in `lesstif.eclass'. problem is I can't think of anything else useful to put there...] Another question is, which version of Lesstif is the most stable. 0.93.36 and 0.93.4x both have some serious known problems (text selection in XmText is broken, rightclicking in OptionMenus acquires a grab and does not release it, ...). 0.93.91 was announced Sept 15 on the mailing list, but from the web site it is not clear if it is considered latest stable yet. Personally, I'd suggest 0.93.18 (and upgrade to 0.93.91 later?) [testing 0.93.91 right now]
Ok next round, commited a new lesstif-0.93.91 which installs to /usr/LessTif and openmotif-2.1.30-r2, please take a look at them. I would vote for completly removing openmotif 2.2 from portage. Opera does work with openmotif-2.1.
Ahh, too late... I was a bit busy testing 0.93.91 this week and going to attach my own version which looks almost identical ;). In general, 0.93.91 looks very stable and the bugs in .3x and .4x seem to be fixed (changelog is a bit unclear though). Only minor thing is, 0.93.91 needs libfreetype, which means programs that link to the static libXm.a will need `-lfreetype'. [In my version I have changed lesstif's mwm's name and resource class to mwm-lesstif and Mwm-lesstif, respectively, so users can use it independantly of motif's mwm. Not sure if these changes are too intrusive... I'll attach it below for review] Removing Openmotif-2.2 from the tree (at least for some time, until some program needs it) sounds good... or at least makes the update path somewhat easier. [warning: ugly hack ahead] If openmotif-2.1, in its src_install(), copies libXm.so.3* to `${D}/usr/X11R6/lib' for some period of time, programs built against openmotif-2.2 will continue to work without rebuilding [/warning]. However, it shouldn't hurt anything to put 2.1 in slot 2.1, if 2.2 needs to be put back in... (some people say I'm looking too far beyond the horizon sometimes, but just in case...;)
Created an attachment (id=20039) [details] lesstif-0.93.91.ebuild (just for discussion of the mwm part)
Created an attachment (id=20040) [details] lesstif.eclass * used to tell ebuilds where lesstif is
Created an attachment (id=20041) [details] nedit-5.4_rc2.ebuild new test ebuild * needs `lesstif.eclass' * needs this patch http://bugs.gentoo.org/attachment.cgi?id=19081&action=view (nedit-5.4RC1-gentoo_pre.diff)
*** Bug 32551 has been marked as a duplicate of this bug. ***
I think following the FHS should be one of our goals if possible, here one solution: For headers we can do the following: /usr/X11R6/include/Xm/1.2/Xm /usr/X11R6/include/Mrm/1.2/Mrm /usr/X11R6/include/uil/1.2/uil /usr/X11R6/include/Dt/1.2/Dt and /usr/X11R6/include/Xm/2.1/Xm /usr/X11R6/include/Mrm/2.1/Mrm /usr/X11R6/include/uil/2.1/uil /usr/X11R6/include/X11/2.1/X11 this is also the way gnome supports 1.4 and 2.x installed at the same time. --- Same for libraries: /usr/X11R6/lib/motif/1.2 and /usr/X11R6/lib/motif/2.1 --- Binaries should be postfixed by the version number and a tool called motif-config should link the required version to the original names: mvm -> mwm-1.2 mwm-1.2 mwm-2.1 uil -> uil-1.2 uil-1.2 uil-2.1 ... --- Finally the man pages: it could be done the same way like the binaries, but I'm not sure here.
[argh...this is going to take longer than I thought] To speed things up a bit, why don't we just export LESSTIF_INCDIR LESSTIF_LIBDIR (LESSTIF_BINDIR) separately and worry about the final location later. The bigger problem right now (and for the last couple of months) is that current Lesstif ebuilds do not cooperate very well with Openmotif, yet most Motif progs depend on either `virtual/motif' or Openmotif directly, and another pkg (cmucl) depends on lesstif. [cmucl does work with openmotif, it's just difficult to come up with a patch until the final layout is decided on]
*** Bug 27606 has been marked as a duplicate of this bug. ***
Sorry for taking so long to response. But I don't think defining a lesstif dir is enough, since my suggestion also changes openmotif's directories. If we can make a decission i'll come up with the ebuilds within a week.
NO! not again such a ``solution'' like for qt and kde. the solution presented by Comment #46 is very good imo. it fits nicely into the fhs and uses an similar approach like gnome does. by symlinking the libs into /usr/lib (only lib${name}.so.[0-9]) you dont even need a extra entry in /etc/ld.so.conf. having ${LESSTIF_DIR}/{bin,include,lib} or something like that makes me cry...when you continue to do so,you'll end up in a filesystem structure similar to windows. keep sorting files hierachically by type (binary,header,library) not by program. PS: the proposed LESSTIF_BINDIR whould be sth. like /usr/bin/motif/1.2 or /usr/bin/lesstif
Like I already said somewhere else, actual locations don't matter as long as there is one default (development files accessible from standard locations) and one or more alternatives (development files are in private dirs and provisions are made to make their locations known to packages if their respective maintainers choose to support the alternatives). bin/uil is a development file in this context (libMrm can't read .uid files compiled with uil from a different motif implementation). One problem I see with `motif-config' is if `/usr' is globally shared via NFS though... * all hosts that share the same `/usr' will share the same config. * `motif-config' can't write to `/usr' unless it's called from the server machine. * the admin will force-feed the same config to all users. * (partly solvable by using 2-level symlinks with the variable parts on a local partition -- `/etc/alternatives'?)
we could also drop motif-config and only have the bin's with postfix. what about the manpages?
Manpages is actually the most complex part -- yet except for `mwm' related pages most end users will probably never read them. Prossibly the most "correct" way would be to prepend/append Lesstif's man dir to MANPATH based on some dotfile in the user's homedir from a SuSE-style `profile.d' file...which will require a change to csh.login/baselayout, plus some config script that sets up said dotfile. As a compromise, I'd say we just put Lesstif/man after Motif/man in MANPATH... Motif's manpages are both more detailed and more complete.
what about motif's /etc files?
*** Bug 34014 has been marked as a duplicate of this bug. ***
There are only two file in /etc, both needed by mwm. * `app-defaults/Mwm' is an Xt thing and can't be moved, but if mwm's class name is changed, Xt will look for it under a different name (attachment #20039 [details] uses `Mwm-lesstif'). * `system.mwmrc' and/or `$LANG/system.mwmrc' are expected in `$prefix/lib/X11/mwm', which usually is a symlink to `/etc/X11/mwm'. Two possibilities: * if --prefix is != (`/usr' or `/usr/X11R6'), only the symlink target needs to be changed (attachment #20039 [details] uses `/etc/X11/mwm-lesstif'). * if --prefix is one of the above, we have to change `mwmddir' in `clients/*/mwm/Makefile.am' and re-autoconfig. [or maybe just drop lesstif's mwm...after all it's just an outdated fvwm without modules and mwm-style config files...there'll be complaints either way...]
are the 1.2 and 2.1 config files compatible?
Well...the question is not 1.2/2.1, but rather Lesstif/Motif. In general, config files *are* compatible...lesstif may add a few resources that Motif's mwm does not understand and simply ignores (f.ex. the ability to give titlebars, borders and titlebar buttons different colors...which is of questionable usefulness anyway and is not in the Motif standards). On the other hand, Lesstif does not understand the 2.1 goodies, even in 2.1 mode (internally, 2.1 is still 2.0 in most parts...which hasn't changed in more than 2 years). Again, not a problem as unknown resources are ignored. The real problem is that Openmotif and Lesstif may be installed at the same time and thus must not install files with the same name.
Erm... with "config files" I mean config files and app-defaults.
we could provide the /etc files with motif-config
[still not sure what `motif-config' is supposed to be doing, but could you please make its settings per-user, not per-machine or site-wide?] Didn't even think of it yet, but wrt to an upcoming common menu system, it makes a lot of sense to have a separate package that provides at least `system.mwmrc'...or maybe even a virtual provided by two packages: a plain vanilla version for menu-ignorant people like myself:), and another version with a dynamically created `system.mwmrc' that includes a full-blown applications menu in the rmb menu.
This of course assuming those minor details don't cause any additional delays to the resolution of the initial Lesstif/Motif problem.
motif-config is intended to switch the symlinks for mwm, ui,... to mwm-1.2 or mwm-2.1 or mwm-2.2 and the same for manpages. I currently can't see a per user solution for this. I think we can handle the menu thing later.
are subdirs in /usr/bin allowed in fhs?
subdirs are diallowed in /bin. /usr/bin can have 2 subdirectories according to the FHS: X11 and mh. it does not disallow other subdirs in /usr/bin. as the 2 subdirs are for special programs (or at least a special group) subdirs in /usr/bin for motif and lesstif seem like a solution. don't know if it's a good one. what about a suffix for the binaries? like ${name}-motif and ${name}-lesstif ?
The idea of the subdirs is the user configurable part. If we have /usr/bin/motif/1.2 users can export PATH=$PATH:/usr/bin/motif/1.2 and have motif 1.2 binaries, same for 2.1 or 2.2. If we do symlinks, it will affect the whole system.
bartron: does openmotif 2.1 not include uil?
Hm, technically, yes.
No, wait...are you trying -r1 or -r2? Whoever converted the imake build to autotools, snuck in (among other flaws) some logical errors that make the generated Makefile (silently) ignore all sorts of errors. In the relink-phase, libtool looks for -lXm in `$prefix' instead of `$DESTDIR/$prefix' when building libMrm and libUil, so uil fails too. You need at least the relink-patch from elibtoolize.
yeah, uil failed to build because i hadn't installed yacc
Ouch, guess I should have my eyes checked. My previous comment is of course complete nonesense...somehow misread 2.1 as 2.2...
Just curious, are there arches where imake specifically defines `YaccCmd' as `yacc'? On all linux systems I've seen, it's `bison -y', and bison is in the system profile.
yeah, but somehow it wasn't installed on any of my systems
I have commited lesstif-0.93.91.ebuild (slot 1.2), openmotif-2.1.30-r3.ebuild (slot 2.1) and openmotif-2.2.2-r3.ebuild (slot 2.2) which follow the new structure. I still have to change the search path for the config files to /etc. Then I'll write motif-config (not the top priority) and change the ebuilds of the apps that depend on motif (higher priority ;)).
*** Bug 35297 has been marked as a duplicate of this bug. ***
creating patches for the ebuilds is a bit tricky, would be nice if you could help me out here :)
As much as I hate to repeat myself... I still think one of the three M*otifs should be installed in standard locations, and look the same as on other linux systems -- much easier on developers / users of non-ebuild based packages. That way, the only required change to dependant ebuilds is an updated `DEPEND', and Lesstif support can be added one by one later. Problem is, to not break the systems of users with mixed ~arch/arch installations, you have to update (and rev-bump) *all* ebuilds, all ~arches and arches, current and older versions in portage, all at once (although that idea really scares me, I can't think of a better way... except maybe to get an area outside of main CVS to test things for a while), so it makes even more sense to keep the changes as small as possible.
But I see no way installing it in the default location and being FHS compliant.
? Every Linux distribution I've seen installs Openmotif into `/usr/X11R6'. Can't see anything wrong with that.
and where shall we install lesstif and openmotif-2.2?
OK, i think i got an idea, it is a bit hakish but will work with very small changes to the ebuilds and is FHS compliant. Depending on the use flags (lesstif or motif) we could link /usr/X11R6/include/{Xm,uil,Xt} to the version of includes we need. I hope you understand what I mean ;)
I don't know...I don't like the whole concept of changing symlinks, which may work on pure standalone machines, but causes problems if `/usr' is mounted site-wide via NFS (well not so much for ebuilds as they need write access to `/usr' anyway, but what happens if a user on another machine accesses Motif files at the same time? Questions are, who/what would change those symlinks, and how to make sure they're always in a consistant state? What about libraries that link to Motif, there would have to be a way to make sure programs that link to those libraries link to the same Motif, and possibly many more). In my opinion it's much cleaner if there is one default and one or more alternatives--selection can be done exclusively via `-I' and `-L' switches (plus $PATH, if there ever is a package that needs uil functionality), and the "default" is still available to not ebuild-ized packages (In an ideal world that "default" would of course be Lesstif...but unfortunately it's not ready yet for use with all programs). So where to put the "alternatives"? Definitely easier on .deb and .rpm based systems because packages are usually split into runtime and development parts there--runtime parts can co-exist while development parts "conflict"/block each other (sorry, feel like summarizing right now). Not an option in Gentoo though, which, as a source distro, always needs the development files around (and, speaking as a programmer, I like it better this way). That means, alternative packages have to be moved out of the way, which FHS may not have been written in mind with. Personally, I don't see a real problem with `/usr/lesstif' (many commercial UNICES do something like that, f.ex, Solaris has all CDE related files under `/usr/dt')... FHS, however, says (1) Large software packages must not use a direct subdirectory under the /usr hierarchy. and (2) Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. (Yes, I know it's not meant that way, but I think (2) allows enough room for interpretation to allow for `/usr/lib/lesstif', just as many linux distributions use `/usr/lib/qt'. Any FHS guru around reading this? 3.1415927?) = A different question is, are Openmotif-2.1 and 2.2 needed at the same time? According to the article mentioned in the `URL' field, 2.2 is unmaintained, considered "experimental" by OSF, and "new" features are unsafe to use (it is, however, unspecific if those restrictions apply to 2.2 as a whole or just to "new" features introduced in 2.2...but doesn't matter because as long as there is no program that uses them there is no need to use 2.2). Only reason to have 2.2 in portage is to support programs that are already compiled/linked against `.so.3' libs...in which case a lib-only package (which can coexist with 2.1) would be sufficient. [with that in mind, the more I think of it, instead of slotting, Openmotif-2.2 should probably be renamed to avoid confusion/accidental installation if a user types `emerge openmotif'. Debian (which only provides 2.2 shlibs, no headers, mwm, etc) calls it motiflibs3... however, just in case there is a real Motif-3 some day, I think openmotif22 may be even better]
so here's the conclusions/suggestions I have then: 1. update openmotif-2.1 to install 2.2's libs for compatibility's sake 2. remove openmotif-2.2 entirely 3. I'm fuzzy on this one with regards to openmotif and lesstif cohabitating on the system, though I'm rather inclined to do the hack with -L and -I for those that need it. For instance, /usr/lib/lesstif and /usr/include/lesstif should take care of most of it, no?
> update openmotif-2.1 to install 2.2's libs for compatibility's sake do you mean to provide the original libs, or just symlinks to openmotif-2.1?
Since I'm on this bug's CC list, I might just as well throw in my $0.02 .. 1. Symlinks are bad. 2. Why not make a clean cut and dump om-2.2 alltogether? As already discovered multiple times, it offers no (usable) new functionality, or to quote from one of the Motif sites, causes pain but no gain. Any program which uses the new functionality should be considered broken cuz you won't be able to legally compile it on non-free operating systems. Nedit-5.4 features a compile-time check and refuses to build with om-2.2. Does a "gentoo-enterprise" really need more than one Motif? Gentoo is different from SuSE, RedHat and Mandrake in that it does not have to brag with "bleeding-edge" version numbers just to sell a otherwise identical new version of their OS.
IMO the /usr/{bin,include,lib}/{motif,lesstif} (or something like that). is the best fhsish solution..perhaps you could create /usr/share/{motif,lesstif}/prefix/{bin,include,lib}, where bin,include and lib link to the right places and provide /usr/share/{motif,lesstif}/prefix as motif prefix to programs....only an idea...(of cause runtime libs are directly symlinked into /usr/lib)
I thought "share" is for architecture independent data only, data which can be "shared" between different hardware platforms? But why invest so much time in Lesstif support? Most business users don't need 2 implementations of the same stuff. Look at the forums and gentoo-user. Most end users see Motif as a needed library which is missing from time to time. They don't know or care what it does.
yes its architecture independant,as it only contains symlinks,which link to architecture independant data,but do not depend themselves on the arch.. PS: because this is gentoo,and you should always be able to choose....
Maybe we should split the whole thing into 2 parts: 1a. [top priority] Move Openmotif and Lesstif out of the way of each other. I think the best way is to announce Lesstif's install location to ebuilds via one or more eclass variables and install Lesstif, well...somewhere for now (somewhere != `/usr' && somewhere != `/usr/X11R6') 1b. [lower priority] update ebuilds to optionally build against Lesstif if possible (possibly should go in some sort of policy guide). 1c. [lower priority] decide on a Lesstif location that is most FHS compliant (this won't affect already converted ebuilds). 2. decide on the version of Openmotif to use for all source based packages (finally found the time to have a look at Openmotif-2.2.3. From looking at the Changelog, some of the problems in 2.2.2 seem to be solved, however... lots of inconsistancies: * there are still 2 files with build instructions...one describing autotools, the other one describing imake. Most of the missing Imakefiles in 2.2.2 are back, yet the RELNOTES file says imake is no longer supported. * one subdir still looks for headers in system dirs first when building with autotools (seems to be unreported yet...reporting upstream once I get it to build). * `LICENCE' is still a verbatim copy from 2.1.30 from the OpenGroup. * (nonfunctional) demo programs are still installed in system dirs. * The autotools and the imake build both don't build for me out of the box...each bailing out at different places) * To be fair, 2.2.3 was officially announced as a beta release. IMHO 2.1.30 should still be the better choice until 2.2.4?. PS: [re: 2nd paragraph comment #89] Please don't do that, it's an easy way to start a religious war! Believe me, there are/will be users who *do* care.
Ouch, major typo!...bad copy&pasting from dir listing. `LICENCE' is of course meant to read `INSTALL.imake'.
I think this is really the way we have to go since i wanna fix this situation for the 2004.0 release. I updated the lesstif and openmotif-2.1 ebuilds and comitted motif.eclass to fix 1a. Please take a look at them.
my $0.04: as far as conflicts with om are concerned, looks good to me -- but: . try to run strings on lib*,mwm,uil,... -- there's hardcoded paths in them based on --prefix . library symlinks should be relative -- otherwise they won't point to the correct file nomore if root != / . nedit 5.4 don't like no lesstif 0.93.91 . merry xmas
>. try to run strings on lib*,mwm,uil,... -- there's hardcoded paths in > them based on --prefix I couldn't find hardcoded paths. >. library symlinks should be relative -- otherwise they won't point to > the correct file nomore if root != / will fix that. >. nedit 5.4 don't like no lesstif 0.93.91 it will soon ;)
To tell the truth--I'm not sure anymore if these paths are based on --prefix or something else, but they sure exist. There's /usr/include/X11, /usr/lib/X11 (due to compatibility symlinks same as /usr/X11R6/include/X11 and /usr/X11R6/lib/X11) and also the place mwm looks for config files. (all shared with Openmotif now) Lesstif also looks for /usr/lib/Xm/bindings--just doesn't any files there.
bash-2.05b# ls libXm* libXm.so.1 libXm.so.3.0.1 libXmu.so.6 libXmuu.so libXm.so.1.0.2 libXmu.a libXmu.so.6.2 libXmuu.so.1 libXm.so.3 libXmu.so libXmuu.a libXmuu.so.1.0 I made a test with Opera 7.50 P1 and 7.23: 1. I have enabled in my system openmotif 2.2.2-r1 and lesstif 0.93.40. Ok, I upgraded lesstif to the most recent 0.93.94, and now Flash plugin not loads, then I called Opera from terminal using the option "-debugplugin" and at time to load a Flash animation, Opera asks for libXm.so.2. This librarie isn't more present in my sistem as you can see above. When lesstif 0.93.40 was unmerged, libXm.so.2 was deleted. Is This a correct behavior? If a user is have Opera so have to use lesstif 0.93.40? Thank you...:-)
Since opera supports both `libXm.so.2' and `libXm.so.3', (opera-7.2x that is, never tried 7.50), I think the cleanest solution is to check the installed version at runtime: http://bugs.gentoo.org/show_bug.cgi?id=31205#c10 re: comment #96: Will have to look into that...`/usr/lib/X11/include' most likely is the place where Motif's pixmap cache looks for `xm_*' replacement pixmaps (those little pixmaps displayed in Xm message boxes). [as for the other dirs, see later comments]
I think opera is no problem, since we will drop libXm.so.3 completly for now and lesstif only provides libXm.so.1. My current plan is to mark the new openmotif-2.1 and lesstif ebuilds stable next week, remove openmotif-2.2 from portage and change the deps from virtual/motif top x11-libs/openmotif. Then we can begin to add support for lesstif.
I just removed operamotifwrapper from /opt/opera75/lib/opera/plugins remaining only the archives below: libnpp.so operamotifwrapper-3 operaplugincleaner Now works fine...
wait! do i understand you right? you want some kind of unification only providing `one' motif-like (motif-* lesstif) library? nice...what's next? drop kde in flavour of gnome (or vice versa)
no it means we drop virtual/motif, make openmotif the default, but give the user the choice of lesstif via useflag i sent a announcement of the changes to gentoo-dev and if there are no complaints i'll be ready to change things on sunday
No, actually users will have a finer-grained control on which Motif applications will be build with. To summarize, there are 3 (or maybe 4) different (free) Motif implementations available: 1. Lesstif in Motif 1.2 mode (libXm.so.1) 1. Lesstif in Motif 2.1 mode (libXm.so.2) 2. Openmotif 2.1.30 (libXm.so.2) 3. Openmotif 2.2.2 (libXm.so.3) On the other end, Motif programs can be classified as follows: a. apps that don't use 2.1 features (without having exact numbers, should be the vast majority) - usually rock solid with Lesstif 1.2 and Openmotif-2.x b. apps that need 2.1 features - most stable with Openmotif-2.1 - may or may not work correctly with Lesstif 2.1 (some of Lesstif's 2.1 features are not 100% completed yet or tested as thoroughly as 1.2, see release notes/anouncement) c. progs in (a) or (b) with known issues with Openmotif-2.2 Put together, this means: - every Motif program in portage is stable with Openmotif-2.1 - since there can only be one `libXm.so.2' on the system, Lesstif is only compiled in 1.2 mode (not a problem because the few programs that explicitely require 2.1 features, according to their documentation, should not be build with Lesstif anyway if maximum stability is desired. 1.2 programs don't lose anything with Lesstif in 1.2 mode).
Or, in fewer words, what Heinrich says (sorry, somehow missed your comment).
*** Bug 38046 has been marked as a duplicate of this bug. ***
I have need for Pro/Engineer at work. Unfortunately Pro/E requires libXm.so.3 and I can't convince the Pro/E R&D group at work to rebuild against libXm.so.2 (the target supported platform is redhat which includes libXm.so.3). Are there any plans to continue with the SLOT idea so that OpenMotif 2.2.x would still get installed?
I have the same issue with Realsoft3D. It requires libXm.so.3 to run.
bartron: any news on motif-2.2.3 or lesstif's 2.1 mode?
*** Bug 53759 has been marked as a duplicate of this bug. ***
*** Bug 40765 has been marked as a duplicate of this bug. ***
"IBM Client Access for Linux" is another application which needs libXm.so.3 Is anything happening on this issue? What needs to be done to get Openmotif-2.2 back in portage without breaking everything. This issue is stopping me from deploying Gentoo in our company. If I can help to resolve this, I will.
Any chance we can see this fixed anytime soon? How do the other distros deal with it? Every other distro I know of ships with openmotif 2.2.x and libXm.so.3. This bug has been lingering around for nearly a year.
*** Bug 65699 has been marked as a duplicate of this bug. ***
any solution found yet?
Finally, I *really* need spdbviewer that uses libXm.so.3, openmotif-2.2.2, how could I get the libraries? Thxs Alcino
it seems that there are more programs requiring openmotif-2.2 is there any way that some of the newer people to join gentoo ( people who knew nothing of the old disputes here) would be able to help in getting this back on track I personnally need libXm.so.3 for atleast 3 programs i am trying to use
So I've read all the arguments against OpenMotif 2.2. I haven't validated them in source yet, but I agree that if all of that is true, then yeah, there is a good reason to not deliver OpenMotif 2.2.x yet. BUT, IMO, this is entirely trumped by the fact that the two "standard" Linux distributions (RedHat/Fedora and SuSE) both deliver OpenMotif 2.2.x by default. Looking back at the history of this bug, it looks like the primary driving factor for removing libXm.so.3 was: "Technically, it *could* install into its own slot, but since it offers no (usable) new functionality, and is incompatible with commercial, binary-only packages" Maybe back a year ago, this was true, but now nearly all the big commercial binary-only motif based programs use libXm.so.3 now since they're targetted for the biggies. This really puts gentoo in a less than ideal position when compared to the other distros. It just seems it's time to gentoo to keep up with the pack with this regard. Although, I'll have to admit, it's pretty damn easy to download openmotif yourself and just build it manually and use LD_LIBRARY_PATH for just the binaries the need it. That's what I did.
What ever you're going to do, please steer clear of Openmotif 2.2.3--it's libXm.so.3 ain't compatible w/ binaries built with libXm.so.3 from Openmotif 2.2.2. Spontanious but reproducible crashes. Program vendor says 2.2.3 is unsupported.
i think while openmotif-2.2.3 is entering portage, this bug is finally fixed
Ok, initial ebuilds are now in portage, hardmask though: openmotif-2.1.30-r7 (slot 2.1) openmotif-2.2.3-r1 (slot 2.2) lesstif-0.94.0-r1 they all provide virtual/motif and install their files in: /usr/lib/$package /usr/include/$package /usr/bin/binarie-$package /usr/share/man/manpage-$package where $package stands for openmotif-2.1, openmotif-2.2 and lesstif the next task to do is write the motif-config script
*** Bug 81829 has been marked as a duplicate of this bug. ***
there is now motif-config-0.1 in portage, please test it with above mentioned lesstif/openmotif versions
There are a lot of shell functions in motif-config that should be changed to use 'return <status>' instead of 'exit <status>'. I guess you only want to break out of the shell when uid != 0.
Could you please attach a patch with all statements fixed? But I think if [ "$(id -u)" -ne 0 ] then eerror "$0: Must be root." exit 1 fi Is correct, if you are not root and try to run a option that needs root, why not exit the whole script?
I went through motif-config again, motif-config-0.2 is the result, please take a look at that
Should line 90 under _deactivate_profile() be "return" instead of "exit 1"? CONFIG_FILE does not exist for new installation, but it is impossible to create the file since the script will exit during _deactivate_profile().
sorry, please emerge motif-config-0.2 again, the old ebuild just installed the 0.1 version again
I guess you should take a good look at the gcc-config and binutils-config scripts, right now its a mixture of paradigms... ;-) Either you want to loop over all actual parameters (making the script agnostic to parameter order) or decide which order the actual parameters should have. The two other scripts mentioned above goes for the first solution, the motif-config scripts does a bit of both... which breakes things when fixing the 'exit' vs 'return' usage I mentioned in http://bugs.gentoo.org/show_bug.cgi?id=29388#c123
i wanted to go for the second one and think it's fixed in motif-config-0.2 (finally)
Heinrich, could you please look at bug #78111 comment #35 again? Points 2 and 3 there are still not addressed. (2) Despite what nedit developers think, nedit-5.5 is not very stable with at least Gentoo's openmotif-2.2.3 (crashes are rare but always happen when you least suspect them, http://www.nedit.org/archives/develop/2003-Jul/0028.html and/or http://www.nedit.org/archives/develop/2003-Jul/0029.html). Can't use Lesstif either because the last supported Lesstif version is 0.93.94 in 2.1 mode (only version in portage is 0.94.0) and 0.93.18 in 1.2 mode. (only version in portage is 0.93.94, a masked version at that) (3) Certified Red Hat 9 programs that make use of openmotif's standard font selection dialog are not compatible with Gentoo's openmotif 2.2.3 (Program vendor says it's a Fedora thing which they're not going to support, ever).
Point 2: You can build nedit-5.5 with every release in portage. If nedit crashes, it's not a motif fault but a nedit fault, so we need patches for nedit. Point 3: What can I do?
Point 2: I can't officially. First, last time I synced nedit-5.5 depends on x11-libs/openmotif. Only stable version in portage is 2.2.3, and that one in not very stable. Only stable Lesstif version in portage is 0.94.0, and that is untested according to check_lin_tif.c (and how does one build against Lesstif anyway if motif-config is only in ~ ?) Point 3: I'm still researching that one, but as it looks like Fedora is shipping a Motif version that is incompatible with the version used in their stable products, despite identical library versions.
Point2: This will be fixed when motif-config is stable Point3: I took the patches from fedora, so don't understand why the application don't work
Point3: That's what I said. Fedora ships with a libXm.so.3 that is incompatible with programs built against a Motif version used in stable Red Hat products. You want patches from Red Hat, not Fedora.
I don't want to sound impatient, but what is the progress here? With stable-only ebuilds it's still (since Jan 2005) not possible to get a stable nedit (Openmotif 2.2.3 causes problems, Lesstif 0.94.0 is untested). Unstable land has too many problems to be a real alternative (bugs #82902, #83018, #83154, #83422, #83744, #84243, #84266, #84609, #84915, #85151, #86201, many are closed but not really fixed)
Questions for bug-opener: 1. Why do openmotif and lesstif disable the sandbox? Isn't that dangerous? 2. Why are emerges wrapped inside these messages? * Starting installation of a new motif version. * Note: You can't use any motif app during this process. [30 minutes later...] * Finishing installation. * Note: You can now use your motif apps again. 3. Didn't you used to be against flipping around symlinks? What happened to your earlier concerns about libraries and programs using them linked to different motif-libraries? What about globally nfs-mounted /usr partitions? Libtool going crazy? (I can already see motif's equivalent of 'fix_libtool_files', only it's not only needed after new versions but everytime motif-config selects a different profile).
I just installed openmotif-2.2.3-r6. i noticed that /usr/lib/opemotif-2.2/ is added to /etc/ld.so.conf, why not link /usr/lib/openmotif-2.2/libMrm.so.3,libUil.so.3 and libXm.so.3 to /usr/lib, so the runtime linker finds them directly? when you only link the .so.$number libraries they shouldn't conflict with other versions. looks like a cleaner solution to me,isn't it?
Comment #136:
Comment #136: I don't really know, wasn't my idea... looks like the ebuilds delete things on the life filesystem during `src_unpack' and restore these links at the end of `src_install'... not possible inside sandbox. As for the reasons, no idea, ask Lanius. The bigger danger I see though is if some operation inbetween errors out... in that case nothing is restored. Comment #137: I'd vote for that too (again).
Comment #136 again:
Comment #136 again: Now that I look at it, there's indeed a security issue in the newer (~) ebuilds... they touch files in `/tmp' with predictable names. Heinrich, please have a look at bug #87341.
Tom, now that we have your attention, could you please look at comment #130? Also, comment #131 tells me I can build nedit-5.5 with every release in portage. Basically true, but there doesn't seem to be some way to make my choice permanent. For instance, right now emacs, tetex, cmucl, and probably many more ebuilds honor a useflag, "lesstif". Once motif-config moves to stable, I will have to be very careful the right version is selected on every update.
Interesting. Is there a chance to get the old behaviour back before the new ebuilds go stable? This ain't very convenient.
Incompatibility between 2.2.2 and 2.2.3. Widget recources (they're like `properties' in delphi/vcl) are accessed via string constants. To avoid having to export thousands of symbols, libXm exports only two symbols, `_XmStrings[]' and `_XmStringsI[]', and all class, resource, etc. names are defined as offsets into these two huge strings, first being public and the latter for internal use only. For some reason, all new constants in openmotif-2.2.2 have been appended to `_XmStringsI[]' (which means they aren't officially available... all widget public header files added in 2.2.2 include `<Xm/Ext.h>', which includes `<Xm/XmStrDefsI.h>', which is not installed by default and should not be used outside libXm itself, but that's another issue). In 2.2.3 and 2.2.4 they are moved to `_XmStrings22[]' and `<Xm/XmStrDefs22.h>', resp., so what happens is that your program (I'll use the font selector as an example) accesses `XmNcurrentFont' as `_XmStringsI[6625]' when in 2.2.3 and 2.2.4 it is #define'd as `_XmStrings22[2046]' (which won't lead to any meaningful value... `Xt[Va]GetValues()' most likely leaves the return arg untouched). In fewer words, 2.2.2 programs/libraries that use any of these constants >= `XmNitemFoundCallback' don't work with 2.2.3 and 2.2.4. I'll put together a small demo program later. As for the other question, you should probably file an enhancement request against `motif-config'...
Forget my last comment, already been done... bug #86822
Created an attachment (id=55420) [details] testprogram comment 142
Created an attachment (id=55420) [details] testprogram comment 142 (adjust prefixes in Makefile as necessary, `make run' runs with libXm.so.3.0.1 (openmotif-2.2.2), `make run223' runs with libXm.so.3.0.2 (openmotif.2.2.3).
Confirmed here. Sample program runs correctly w/ om-2.2.2 but not with om-2.2.3. Why is Gentoo compatible w/ Fedora but not RHEL and SLES? Why is #86822 "invalid"? x11-misc/xplore does not look pleasant w/ lesstif. How do I make sure it is always compiled w/ motif? What happened to your high quality standards from 2 years ago? Why is bug #87341 still not fixed? Combined with "SANDBOX_DISABLED="1"" there's way worse exploits than /etc/nologin? If bug #86897 is accurate, why is om stable on ppc-macos? So many questions, no answers.
I have another question. Motif, and especially lesstif is broken for more than 3 months now, are those two even supported anymore? Will it ever be possible to build lesstif without runtime dependencies on openmotif? Is anyone even listening to lesstif bugs?
sorry, bartron I suggest we start with the libtool thing (mentioned in #85151 and #89482, both appear to be "fixed") Below is the requested information, results are mainly identical with vanilla Gentoo running XFree-4.3.0 or XOrg, each tested with libtool 1.5.6, 1.5.10 and 1.5.14. In Mandrake (lesstif in /usr/X11R6) the first search spec is -L$RPM_BUILD_ROOT/$libdir. If prefix is some private dir, it's -L/usr/X11R6/lib -L$inst_prefix/$libdir -L$libdir -L$inst_prefix/usr/lib -L/usr/lib, again tested with 1.5.6, 1.5.10 and 1.5.14 Bug in lesstif? libtool? both? [call to libtool] /bin/sh ../../libtool --mode=install /bin/install -c 'libMrm.la' '/var/tmp/portage/lesstif-0.94.0-r2/image//usr/lib/libMrm.la' libtool: install: warning: relinking `libMrm.la' (cd /var/tmp/portage/lesstif-0.94.0-r2/work/lesstif-0.94.0/lib/Mrm-2.1; /bin/sh ../../libtool --tag=CC --mode=relink gcc -march=i686 -O2 -fomit-frame-pointer -o libMrm.la -rpath /usr/lib -version-info 2:1 -no-undefined Mrm.lo lookup.lo misc.lo ../Xm-2.1/libXm.la -L/usr/X11R6/lib -lXt -lSM -lICE -lX11 -lfreetype -lfontconfig -inst-prefix-dir /var/tmp/portage/lesstif-0.94.0-r2/image/) [resulting call to linker] gcc -shared .libs/Mrm.o .libs/lookup.o .libs/misc.o -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../ -L/usr/X11R6/lib -L/var/tmp/portage/lesstif-0.94.0-r2/image//usr/lib -L/usr/lib -lXm -lXt -lSM -lICE -lX11 -lfreetype -lfontconfig -march=i686 -Wl,-soname -Wl,libMrm.so.2 -o .libs/libMrm.so.2.0.1 Full logs in the mail shortly.
libtool In the libtool call `../Xm-2.1/libXm.la' comes first, and so should `-L$inst_prefix/$libdir' (technically it should always be first, but that's a different issue). The bigger problem is `-L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../' (==`/usr/lib/')... Just to be sure, what's in libXm `dependency_libs' (installed and uninstalled versions)?
Ha, good catch. Just looked to me like some innocent compiler-internal directory... libXm.la: dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \ /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../..//libfreetype.la -lfontconfig' libXm.lai: dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \ /usr/lib/libfreetype.la -lfontconfig' But shouldn't libtoolize (or elibtoolize in -r2) have corrected that?
In the days of libtool 1.4.3... yes (libtool 1.4.x (x<3) wouldn't look for installed libraries in $DESTDIR when 1.4.3 would, so simply replacing ltmain.sh with the 1.4.3 version did the trick). So we have two problems here... (a) libtool "finds" libfreetype.la in one of the compiler internal directories and thinks (by string comparison) `/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../..//libfreetype.la' and `/usr/lib/libfreetype.la' are two different files and thinks it knows better than gcc itself where to look for libraries first (this one should be easy to solve... just match the whole "word" with `//' followed by `libfreetype.la' in it and replace with result of `freetype-config --libs`). (b) `-L/usr/X11R6/lib' is before anything else... which means if `/usr/X11R/lib' is the same as `/usr/lib', `/usr/lib' is still first, and if not, well... ld will link to what is in `/usr/X11R6/lib'...
gcc-3 gcc -shared .libs/Mrm.o .libs/lookup.o .libs/misc.o -L/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../ -L/usr/X11R6/lib -L/var/tmp/portage/lesstif-0.94.0-r2/image//usr/lib -L/usr/lib -lXm -lXt -lSM -lICE -lX11 -lfreetype -lfontconfig -march=i686 -Wl,-soname -Wl,libMrm.so.2 -o .libs/libMrm.so.2.0.1 libXm.la: dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \ /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../..//libfreetype.la -lfontconfig' libXm.lai: dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \ /usr/lib/libfreetype.la -lfontconfig' gcc-2 gcc -shared .libs/Mrm.o .libs/lookup.o .libs/misc.o -L/usr/lib/ -L/usr/X11R6/lib -L/var/tmp/portage/lesstif-0.94.0-r2/image//usr/lib -L/usr/lib -lXm -lXt -lSM -lICE -lX11 -lfreetype -lfontconfig -march=i686 -Wl,-soname -Wl,libMrm.so.2 -o .libs/libMrm.so.2.0.1 libXm.la: dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \ /usr/lib//libfreetype.la -lfontconfig' libXm.lai: dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \ /usr/lib/libfreetype.la -lfontconfig'
"/usr/lib//libfreetype.la" != "/usr/lib/libfreetype.la"... sweet. I could think of three possible solutions... (1) Don't install `libfreetype.la' (it's redundant anyway)... (since it's already on most users' systems, not really a solution) (2) Revert to the libtool-1.4.3 behavior of sticking `-L$DESTDIR/$libdir' first at the linker command line... (since the lesstif ebuild invokes either `libtoolize' or `elibtoolize', this adds a dependency on a particular libtool version or libtool patch and may start to fail at some point in time) (3) Skip relinking step... (its only purpose is to change RPATHs from $builddir to $prefix/$lib... since RPATHs are pointless here anyway, this seems like the most sensible solution)
From a technical point of view I'd vote for (3) too, but...please help an old man out who thinks of libtool as some kind of black magic...what are the exact steps?
after `configure': perl -pi -e 's/^(hardcode_into_libs)=.*/$1=no/' libtool (no RPATH in shared libs... libtool already does that if $libdir is in `/etc/ld.so.conf', but it doesn't hurt...) before `make install': for f in `find . -name \*.la -type f` ; do perl -pi -e 's/^(relink_command=.*)/# $1/' $f done
Ha, thought there would be some command line switch ;). Anyway, does exactly what I want on all mainstream arches (x86, x86_64, amd64). Next point on agenda: motif-config.
EXCELLENT!! Any chance to see this in portage soon?
sorry for the absence.. what ld problem does this fix? the relinking to openmotif libraries problem? openmotif-2.1 has the same problem as lesstif when openmotif-2.2 is already installed, does this fix help as well? ok, motif-config. most problems with motif-config arose because of upgrade problems, when an old version was still installed, i'll fix those with blocking the old versions, so you'll start with a clean motif installation. other as that i haven't seen a serious bug.
Huh? Is that a trick question? This fixes exactly the problems as described in bug #85151 and bug #89482, just like I said in comment #147. This fix does not help openmotif-2.1 because openmotif-2.1 does not exhibit this problem, and does not use libtool.
ok, new versions in portage, please test
re: comment #157:
re: comment #157: openmotif-2.2.3 is affected too... with the included libtool (1.4.3) library search order is -L/var/tmp/portage/openmotif-2.2.3-r6/image//usr/lib -L/usr/X11R6/lib -L/usr/lib After `libtoolize' (libtool updated to 1.5.14) search order becomes -L/usr/X11R6/lib -L/var/tmp/portage/openmotif-2.2.3-r6/image//usr/lib -L/usr/lib
So....could we move on to motif-config?
but this order isn't better, is it, since /usr/X11R6/lib is a link to /usr/lib
Tobias (comment #161), Please one thing at a time. For problems with motif-config, please file a separate bug or add to an existing one. These are my personal random thoughts... 1. Multiple, binary incompatible libraries providing same virtual - I think this has been covered here several times why I think there are disadvantages with this approach... a simple test case, build an application depending on `virtual/motif' on machine A which has lesstif installed... move package to machine B, identical to A, exact same packages, exact same USE flags, only difference on B `virtual/motif' is provided by openmotif... package installs with all dependencies satisfied, but won't run because actual virtual providers are incompatible. 2. Emerge results influenced by local settings on build machine - active `motif-config' selection influences emerge results but influencing factors are not recorded in package database. (I think there used to be a policy that would not allow that...) 1a. and 2a. User/Admin preferences - runtime dependencies may change after batch upgrades (I think Bug #86822 would be the right place to discuss this) 3. motif-config in lesstif - lesstif cvs had an identical-named utility first (now part of lesstif-0.94.4)
Heinrich (comment #162), This order isn't better regardless of `/usr/X11R6/lib' being a symlink or not... in the first case because `/usr/lib' is searched implicitely (but usually last, never first), and in the second case because there may be a libXm.{so,a} in `/usr/X11r6/lib'. Best approach seems to me, in order of preference... (1) Don't libtoolize and instead include any necessary patches to the 1.4.3 ltmain.sh in `$FILESDIR' (no dependency on moving target). (2) Turn off relinking.
1. Yes, but it's the best way i can find 2. Doesn't every *-config influence this settings? 1a/2a: Yes after a first motif-config has been stable, we can think about such a feature. 3. Fixed meanwhile. Regaring openmotif relink stuff. Do i have to include the same lines like in the lesstif ebuild. Is there no harm?
no comments? seems like the current version of motif-config works as espected, no bug reports yet
Ain't working as expected here--although, our definitions of expected may be different. The problem with "no comments" seems to me your calling "fixed" way to fast when in fact it's still broken--you're discouraging bug openers that way. Let me give you a small sample of examples out of dozens from the last months Bug #85151 - Lesstif libraries link to Openmotif . reopened and "fixed" so many times, and still broken. Final comment is "it will be fixed in stable when the testing ebuilds go into stable". Many people would think it *ain't* fixed until it's in stable, and on top of that, unstable is broken too. This bug is still not fixed, but "fixed". Bug #88661 - lesstif needs newer libtool but does not depend on it . duplicate of a fixed bug, but problem still exists. I'd call that not fixed. Bug opener already gave up on Gentoo. Bug #90774 - lesstif-0.94.4 installs /usr/bin/motif-config . Last comment is "thx, fixed", but it ain't. Bug #88906 - emerge lesstif-0.94.r6 reports errors but completes successfully . supposedly "fixed" although ebuild itself did not change at all -- with real error checks as taught in the ebuild howto bug #90774 would have, and still would, show up at emerge time. Bug #90522 - nedit crashes (assert) when pressing Preferences->Statistics Line menu . this one still open -- and reproducible here -- but would not exist had you listened to what another reporter told you about Gentoo's own om-2.2.3 -- nedit is not stable even in "stable". Regarding comment #165 1. that is not the best way--users expect virtuals ABI compatible -- current practice is like kde and gnome both providing virtual/desktop -- some packages may work with both but not without recompilation. What you want is something that can be used in conditional dependencies. 2. Which *-config switches between binary incompatible libraries provided by same virtual? 3. still not fixed.
Bug #85151 - Lesstif libraries link to Openmotif: Which unstable ebuild isn't fixed? Bug #88661 - lesstif needs newer libtool but does not depend on it: fixed Bug #90774 - lesstif-0.94.4 installs /usr/bin/motif-config: nobody told me it ain't, now it's for sure Bug #88906 - emerge lesstif-0.94.r6 reports errors but completes successfully: this warnings can safely be ignored Well, the only one still not fixed is: Bug #90522 - nedit crashes (assert) when pressing Preferences->Statistics Line menu What can I do? I don't understand your comment. And the only issue with motif-config that's still under discussion is that it is that different motif versions are not binary compatible, only source compatible. I could raise a warning in motif-config when switching. But since we have 4 motif versions, we can't have a use flag for all of them. I still think motif-config is the best solution, or do you have a better one?
Finally some official response, thank you, but, Bug #85151 is not fixed anywhere, stable or unstable. (Changelog talks about 0.94.0-r7, but that is non-existant, 0.94.4 is broken too, as well as 0.94.0-r2, and all of openmotif-2.2) Bug #88661 - good to hear, but could you please do the same thing in the stable ebuild? There are still people with old libtools who prefer stable, who can't install lesstif right now. Bug #88906 - What the OP told me he means is, you're not checking for any errors at all, i.e., if any of the statements fail, installation still appears to succeed. Instead of 'rm -r foo' it should be 'rm foo || die "bar"', and bug #90774 would have been caught a long time ago. The warnings you talk about are in fact errors (mv returns 1), so if you want to catch real errors, the "harmless" ones will have to go away first (I'm not even sure if POSIX guarantees processing of remaining files after the first error. bartron?) Motif-config - I'd also say it's the worst possible solution. Like you said, missing binary compatibility is a big problem (although it's not the only issue, it's *one* issue that just happens to opens up another whole can of worms). Ignoring all that, you're also chopping off every file (no matter how important they are) that does not fit into it (bug #91951). There's not a single ebuild available that will give a complete motif installation. Why do we need so many motifs?
Bug #85151: somehow it didn't get commited for 0.94.4, fixed Bug #88661: The stable ebuild is not affected Bug #88906, bug #90774: Sorry, but i can't really see how a rm should, error checking here is not neccessary in my oppinion First: It's all about Choice, Second: Motif is cruft, some programs do depend on special versions
Soooo... It's been more than 7 months now and most of the outstanding bugs are still unanswered. Any reason this had to go stable?
Security fix (sort of).
Security fix?
Bug #114234. (Although I could be wrong, it looks a bit like they found some fixed buffers used in sprintf and strcpy calls with some automated tool. Or maybe they just want to save a few potential overflows for another advisory? Either way, sounds peculiar to me. "if ap is user-support data"? And how exactly do you use a shared library remotely? Hmm... Besides, the used patch makes the usual strncpy mistake you've always been allergic to.)
Ugh. One one hand, they only seem to have picked the first `sprintf()'/`strcpy()' directly following the buffer definition... (for instance, in `open_source_file()' there is another `strcpy()' just a few lines down that is called with the exact same data... first one is the main .uil file, second one is an include file specified as absolute path). They're also missing all cases where the used buffer is global, external, inside structures, or passed indirectly. On the other hand, since both examples shown in bug #114234 are triggered by passing too long file names / inc dirs, maybe they're just that, examples... who knows. Whatever the case may be, speculations aren't helping anyone. The used patch definitely needs some work.
So, do you want to take over, or should I?
I'll take it... but let's move that to #114234.
this one is done then, only the security left.
