Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 29388 - "Do we really need 3 different Motif's?"
Summary: "Do we really need 3 different Motif's?"
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Heinrich Wendel (RETIRED)
: 27606 28670 30804 32551 34014 35297 38046 40765 53759 65699 81829 (view as bug list)
Depends on:
Reported: 2003-09-22 15:41 UTC by bartron
Modified: 2006-02-14 01:18 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---

openmotif-2.1.30-r99.ebuild (openmotif-2.1.30-r99.ebuild,2.46 KB, text/plain)
2003-09-22 15:46 UTC, bartron
files/openmotif-2.1.30-imake-tmpdir.patch (openmotif-2.1.30-imake-tmpdir.patch,1.06 KB, text/plain)
2003-09-22 15:48 UTC, bartron
openmotif-2.1.30-r99.ebuild (openmotif-2.1.30-r99.ebuild,2.67 KB, text/plain)
2003-09-24 15:27 UTC, bartron
lesstif-0.93.40-r99.ebuild (lesstif-0.93.40-r99.ebuild,1.76 KB, text/plain)
2003-09-24 15:29 UTC, bartron
openmotif-2.1.30-r99.ebuild (openmotif-2.1.30-r99.ebuild,2.60 KB, text/plain)
2003-10-03 16:48 UTC, bartron
lesstif-0.93.40-r99.ebuild (lesstif-0.93.40-r99.ebuild,1.35 KB, text/plain)
2003-10-03 16:53 UTC, bartron
mgv-3.1.5-r99.ebuild (mgv-3.1.5-r99.ebuild,910 bytes, text/plain)
2003-10-03 16:56 UTC, bartron
nedit-5.4_rc1-r99.ebuild (nedit-5.4_rc1-r99.ebuild,2.09 KB, text/plain)
2003-10-03 16:59 UTC, bartron
lesstif-0.93.91.ebuild (lesstif-0.93.91.ebuild,1.96 KB, patch)
2003-10-31 17:35 UTC, bartron
Details | Diff
lesstif.eclass (lesstif.eclass,104 bytes, text/plain)
2003-10-31 17:37 UTC, bartron
nedit-5.4_rc2.ebuild (nedit-5.4_rc2.ebuild,2.09 KB, text/plain)
2003-10-31 17:39 UTC, bartron
testprogram comment 142 (fontseltest.tar.bz2,33.22 KB, application/octet-stream)
2005-04-05 18:59 UTC, bartron

Note You need to log in before you can comment on or make changes to this bug.
Description bartron 2003-09-22 15:41:45 UTC
[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 <>)

* 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

* 1.2 libs could possibly go in a different package, there's
still one program that uses them: netscape-dyn-motif in 

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
Comment 1 bartron 2003-09-22 15:46:57 UTC
Created attachment 18168 [details]

revised openmotif-2.1, in case someone wants to test if opera works with it.
Comment 2 bartron 2003-09-22 15:48:09 UTC
Created attachment 18169 [details]

required patch
Comment 3 Pierre-Henri Jondot 2003-09-23 02:34:49 UTC
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
Comment 4 bartron 2003-09-23 15:28:58 UTC
  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                                                                   
$ LD_LIBRARY_PATH=/path/to/lesstif-libs ./xmstrtest                             

[a work-around would be to compile all motif apps with 

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]
Comment 5 bartron 2003-09-24 15:27:33 UTC
Created attachment 18281 [details]

remaining conflicts with xfree removed
lesstif block added
Comment 6 bartron 2003-09-24 15:29:43 UTC
Created attachment 18283 [details]

first attemt of a lesstif ebuild that resembles openmotif layout as close as
Comment 7 Heinrich Wendel (RETIRED) gentoo-dev 2003-09-25 12:34:00 UTC
i'll take a deeper look into it later this week, but seems good on the first
view :)
Comment 8 Heinrich Wendel (RETIRED) gentoo-dev 2003-09-25 12:50:53 UTC
and please bump lesstif to the latest version ;)
Comment 9 Heinrich Wendel (RETIRED) gentoo-dev 2003-09-25 12:51:21 UTC
where can i find this netscape-dyn-motif app?
Comment 10 bartron 2003-09-25 16:30:35 UTC
[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
[not installed if using the ebuilds though]
Comment 11 bartron 2003-09-26 17:39:40 UTC
  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'.
Comment 12 Heinrich Wendel (RETIRED) gentoo-dev 2003-09-27 11:07:29 UTC
maybe you should open a bug on
Comment 13 bartron 2003-09-29 15:53:05 UTC
[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 
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 

  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.
Comment 14 bartron 2003-10-01 15:50:10 UTC
  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").
Comment 15 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-02 06:01:48 UTC
so are there any packages that work with lesstif, but not with openmotif?
Comment 16 bartron 2003-10-02 17:43:14 UTC
  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...
Comment 17 bartron 2003-10-02 17:51:15 UTC
[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'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
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]
Comment 18 bartron 2003-10-03 16:48:20 UTC
Created attachment 18704 [details]

almost unchanged, could be final version
* removed virtual/motif
* removed block on lesstif
* added slot 2.1
Comment 19 bartron 2003-10-03 16:53:19 UTC
Created attachment 18705 [details]

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
Comment 20 bartron 2003-10-03 16:56:12 UTC
Created attachment 18707 [details]

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.
Comment 21 bartron 2003-10-03 16:59:06 UTC
Created attachment 18708 [details]

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.
Comment 22 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-04 10:23:57 UTC
*** Bug 28670 has been marked as a duplicate of this bug. ***
Comment 23 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-04 10:25:13 UTC
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
Comment 24 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-04 10:27:12 UTC
all three versions should be installable at once, but packages should preferable
depend on virtual/motif-2.1
Comment 25 bartron 2003-10-04 16:41:43 UTC
  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 to run.
(slotting is so emerging 2.2 won't unemerge 2.1).
Comment 26 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-07 08:26:23 UTC
is there no way to install lesstif and openmotif 2.1 at the same time?
Comment 27 bartron 2003-10-07 17:03:57 UTC
  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 
( or Openmotif-2.1 ( 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 

[[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 (, 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 

* 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).
Comment 28 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-09 22:22:40 UTC
*** Bug 30805 has been marked as a duplicate of this bug. ***
Comment 29 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-09 22:22:56 UTC
*** Bug 30804 has been marked as a duplicate of this bug. ***
Comment 30 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-10 09:10:20 UTC
we can install lesstif and openmotif at the same time, if we install lesstif
in /usr and openmotif in /usr/X11R6
Comment 31 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-10 09:10:36 UTC
that's also the way debian does it
Comment 32 Reporter 2003-10-10 21:35:28 UTC
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.
Comment 33 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-11 11:31:30 UTC
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.
Comment 34 Reporter 2003-10-11 23:17:35 UTC
> 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.
Comment 35 Reporter 2003-10-11 23:23:20 UTC
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.
Comment 36 bartron 2003-10-13 16:46:17 UTC

  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.
Comment 37 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-17 02:59:22 UTC
i think we should discuss that on irc, try to catch me on
Comment 38 bartron 2003-10-18 19:59:34 UTC
[that's what I've been trying for more than two weeks]
Comment 39 bartron 2003-10-25 15:59:40 UTC
[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]
Comment 40 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-31 06:47:05 UTC
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.
Comment 41 bartron 2003-10-31 17:33:40 UTC
  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*
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...;)
Comment 42 bartron 2003-10-31 17:35:38 UTC
Created attachment 20039 [details, diff]

(just for discussion of the mwm part)
Comment 43 bartron 2003-10-31 17:37:39 UTC
Created attachment 20040 [details]

* used to tell ebuilds where lesstif is
Comment 44 bartron 2003-10-31 17:39:21 UTC
Created attachment 20041 [details]

new test ebuild

* needs `lesstif.eclass'

* needs this patch
Comment 45 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-06 11:48:13 UTC
*** Bug 32551 has been marked as a duplicate of this bug. ***
Comment 46 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-06 12:00:41 UTC
I think following the FHS should be one of our goals if possible, here one

For headers we can do the following:




this is also the way gnome supports 1.4 and 2.x installed at the same time.


Same for libraries:



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
uil -> uil-1.2


Finally the man pages: it could be done the same way like the binaries, but
I'm not sure here.
Comment 47 bartron 2003-11-06 18:08:07 UTC
[argh...this is going to take longer than I thought]

  To speed things up a bit, why don't we just export


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]
Comment 48 Seemant Kulleen (RETIRED) gentoo-dev 2003-11-10 18:49:45 UTC
*** Bug 27606 has been marked as a duplicate of this bug. ***
Comment 49 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-13 05:27:42 UTC
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.
Comment 50 Thomas Weidner 2003-11-13 06:56:41 UTC
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/ 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
Comment 51 bartron 2003-11-15 19:21:04 UTC
  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'?)
Comment 52 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-16 02:22:40 UTC
we could also drop motif-config and only have the bin's with postfix. what about the manpages?
Comment 53 bartron 2003-11-17 16:14:07 UTC
  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.
Comment 54 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-20 08:05:35 UTC
what about motif's /etc files?
Comment 55 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-21 06:40:12 UTC
*** Bug 34014 has been marked as a duplicate of this bug. ***
Comment 56 bartron 2003-11-21 06:57:22 UTC
  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, diff] 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, diff] uses `/etc/X11/mwm-lesstif').
  * if --prefix is one of the above, we have to change `mwmddir' in 
    `clients/*/mwm/' 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...]
Comment 57 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-21 10:48:44 UTC
are the 1.2 and 2.1 config files compatible?
Comment 58 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-21 11:37:23 UTC
*** Bug 34014 has been marked as a duplicate of this bug. ***
Comment 59 bartron 2003-11-21 20:20:32 UTC
  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.
Comment 60 bartron 2003-11-21 20:30:14 UTC
  Erm... with "config files" I mean config files and app-defaults.
Comment 61 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-21 22:17:56 UTC
we could provide the /etc files with motif-config
Comment 62 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-21 22:24:08 UTC
*** Bug 34014 has been marked as a duplicate of this bug. ***
Comment 63 bartron 2003-11-22 17:26:00 UTC
[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.
Comment 64 bartron 2003-11-22 17:44:00 UTC
  This of course assuming those minor details don't cause any additional
delays to the resolution of the initial Lesstif/Motif problem.
Comment 65 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-23 00:41:01 UTC
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.
Comment 66 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-23 00:46:18 UTC
are subdirs in /usr/bin allowed in fhs?
Comment 67 Thomas Weidner 2003-11-23 05:53:01 UTC
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 ?
Comment 68 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-23 05:56:45 UTC
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.
Comment 69 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-23 06:24:42 UTC
bartron: does openmotif 2.1 not include uil?
Comment 70 bartron 2003-11-23 17:39:08 UTC
  Hm, technically, yes.
Comment 71 bartron 2003-11-23 17:59:53 UTC
  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.
Comment 72 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-24 03:04:39 UTC
yeah, uil failed to build because i hadn't installed yacc
Comment 73 bartron 2003-11-24 15:20:10 UTC
  Ouch, guess I should have my eyes checked.  My previous comment 
is of course complete nonesense...somehow misread 2.1 as 2.2...
Comment 74 bartron 2003-11-24 16:47:15 UTC
  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.
Comment 75 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-25 07:00:11 UTC
yeah, but somehow it wasn't installed on any of my systems
Comment 76 Heinrich Wendel (RETIRED) gentoo-dev 2003-11-30 12:49:41 UTC
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 ;)).
Comment 77 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-08 07:04:04 UTC
*** Bug 35297 has been marked as a duplicate of this bug. ***
Comment 78 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-08 07:14:26 UTC
creating patches for the ebuilds is a bit tricky, would be nice if you could help me out here :)
Comment 79 bartron 2003-12-12 19:09:49 UTC
  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 
Comment 80 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-13 04:22:02 UTC
But I see no way installing it in the default location and being FHS compliant.
Comment 81 bartron 2003-12-13 18:26:48 UTC

  Every Linux distribution I've seen installs Openmotif into
`/usr/X11R6'.  Can't see anything wrong with that.
Comment 82 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-14 04:18:51 UTC
and where shall we install lesstif and openmotif-2.2?
Comment 83 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-15 07:41:01 UTC
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 ;)
Comment 84 bartron 2003-12-15 17:58:44 UTC
  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

  Large software packages must not use a direct subdirectory under 
  the /usr hierarchy.


  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

(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' 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]
Comment 85 Seemant Kulleen (RETIRED) gentoo-dev 2003-12-15 18:15:05 UTC
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?
Comment 86 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-16 06:43:41 UTC
> 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?
Comment 87 m.o.e. 2003-12-17 16:13:27 UTC
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.
Comment 88 Thomas Weidner 2003-12-18 09:42:37 UTC
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)
Comment 89 m.o.e. 2003-12-18 12:31:49 UTC
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.
Comment 90 Thomas Weidner 2003-12-19 06:06:11 UTC
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....
Comment 91 bartron 2003-12-20 18:47:10 UTC
  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 
    (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 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?.

[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.
Comment 92 bartron 2003-12-20 20:13:12 UTC
  Ouch, major typo!...bad copy&pasting from dir listing.  `LICENCE' is
of course meant to read `INSTALL.imake'.
Comment 93 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-23 06:23:29 UTC
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.
Comment 94 m.o.e. 2003-12-24 18:06:26 UTC
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
Comment 95 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-25 02:29:13 UTC
>. 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 ;)
Comment 96 m.o.e. 2003-12-25 17:24:11 UTC
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.
Comment 97 Carlos Vendramini 2003-12-27 23:30:22 UTC
bash-2.05b# ls libXm*  libXmu.a       libXmuu.a

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 This librarie isn't more present in my sistem as you can see above. When lesstif 0.93.40 was unmerged, was deleted. Is This a correct behavior? If a user is have Opera so have to use lesstif 0.93.40?

Thank you...:-)
Comment 98 bartron 2003-12-30 20:42:57 UTC
  Since opera supports both `' and `', (opera-7.2x
that is, never tried 7.50), I think the cleanest solution is to check
the installed version at runtime:

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]
Comment 99 Heinrich Wendel (RETIRED) gentoo-dev 2003-12-31 04:29:04 UTC
I think opera is no problem, since we will drop completly for now and lesstif only provides

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.
Comment 100 Carlos Vendramini 2003-12-31 07:10:16 UTC
I just removed operamotifwrapper from /opt/opera75/lib/opera/plugins remaining only the archives below:  operamotifwrapper-3  operaplugincleaner

Now works fine...
Comment 101 Thomas Weidner 2004-01-02 10:33:02 UTC
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)
Comment 102 Heinrich Wendel (RETIRED) gentoo-dev 2004-01-08 07:14:28 UTC
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
Comment 103 bartron 2004-01-09 18:54:40 UTC
  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 (
1. Lesstif in Motif 2.1 mode (
2. Openmotif 2.1.30 (
3. Openmotif 2.2.2 (

  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 `' 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).
Comment 104 bartron 2004-01-09 18:56:34 UTC
  Or, in fewer words, what Heinrich says (sorry, somehow missed your 
Comment 105 Heinrich Wendel (RETIRED) gentoo-dev 2004-01-13 08:23:11 UTC
*** Bug 38046 has been marked as a duplicate of this bug. ***
Comment 106 Andy Wang 2004-04-03 18:19:01 UTC
I have need for Pro/Engineer at work.  Unfortunately Pro/E requires and I can't convince the Pro/E R&D group at work to rebuild against (the target supported platform is redhat which includes  Are there any plans to continue with the SLOT idea so that OpenMotif 2.2.x would still get installed?
Comment 107 David Li 2004-04-10 15:08:48 UTC
I have the same issue with Realsoft3D. It requires to run.
Comment 108 Heinrich Wendel (RETIRED) gentoo-dev 2004-05-15 10:14:30 UTC
bartron: any news on motif-2.2.3 or lesstif's 2.1 mode?
Comment 109 Heinrich Wendel (RETIRED) gentoo-dev 2004-08-02 00:51:41 UTC
*** Bug 53759 has been marked as a duplicate of this bug. ***
Comment 110 Heinrich Wendel (RETIRED) gentoo-dev 2004-08-02 00:52:39 UTC
*** Bug 40765 has been marked as a duplicate of this bug. ***
Comment 111 Scott Storck 2004-08-11 10:52:07 UTC
"IBM Client Access for Linux" is another application which needs
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.
Comment 112 Andy Wang 2004-08-12 10:06:16 UTC
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  This bug has been lingering around for nearly a year.
Comment 113 Heinrich Wendel (RETIRED) gentoo-dev 2004-10-05 04:46:50 UTC
*** Bug 65699 has been marked as a duplicate of this bug. ***
Comment 114 Max Lindner 2004-11-10 13:34:07 UTC
any solution found yet?
Comment 115 Alcino Dall Igna Junior 2004-11-19 19:07:03 UTC
Finally, I *really* need spdbviewer that uses, openmotif-2.2.2, how could I get the libraries?


Comment 116 Shawn Stricker 2004-12-10 18:48:18 UTC
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 for atleast 3 programs i am trying to use
Comment 117 Andy Wang 2004-12-27 15:41:08 UTC
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 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 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.
Comment 118 m.o.e. 2004-12-30 18:15:39 UTC
What ever you're going to do, please steer clear of Openmotif 2.2.3--it's ain't compatible w/ binaries built with from 
Openmotif 2.2.2.  Spontanious but reproducible crashes.  Program vendor says 
2.2.3 is unsupported.
Comment 119 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-01 11:01:39 UTC
i think while openmotif-2.2.3 is entering portage, this bug is finally fixed
Comment 120 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-14 06:53:32 UTC
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)

they all provide virtual/motif and install their files in:


where $package stands for openmotif-2.1, openmotif-2.2 and lesstif

the next task to do is write the motif-config script
Comment 121 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-14 06:53:35 UTC
*** Bug 81829 has been marked as a duplicate of this bug. ***
Comment 122 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-15 08:06:15 UTC
there is now motif-config-0.1 in portage, please test it with above mentioned lesstif/openmotif versions
Comment 123 Andreas Vinsander 2005-02-23 09:00:24 UTC
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.
Comment 124 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-23 09:41:55 UTC
Could you please attach a patch with all statements fixed?

But I think 

        if [ "$(id -u)" -ne 0 ]
                eerror "$0: Must be root."
                exit 1

Is correct, if you are not root and try to run a option that needs root, why not exit the whole script?
Comment 125 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-23 09:50:34 UTC
I went through motif-config again, motif-config-0.2 is the result, please take a look at that
Comment 126 Sok Ann Yap 2005-02-23 23:42:22 UTC
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().
Comment 127 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-24 00:06:56 UTC
sorry, please emerge motif-config-0.2 again, the old ebuild just installed the 0.1 version again
Comment 128 Andreas Vinsander 2005-02-25 07:23:45 UTC
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
Comment 129 Heinrich Wendel (RETIRED) gentoo-dev 2005-02-25 09:18:30 UTC
i wanted to go for the second one and think it's fixed in motif-config-0.2 (finally)
Comment 130 Tobias D. 2005-03-08 18:43:42 UTC
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, and/or 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).
Comment 131 Heinrich Wendel (RETIRED) gentoo-dev 2005-03-09 06:59:37 UTC
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?
Comment 132 Tobias D. 2005-03-09 20:27:31 UTC
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.
Comment 133 Heinrich Wendel (RETIRED) gentoo-dev 2005-03-10 05:25:17 UTC
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
Comment 134 Tobias D. 2005-03-10 19:10:36 UTC
Point3: That's what I said. Fedora ships with a that is incompatible
with programs built against a Motif version used in stable Red Hat products. 
You want patches from Red Hat, not Fedora.
Comment 135 Tobias D. 2005-03-21 20:07:39 UTC
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)
Comment 136 m.o.e. 2005-03-29 19:52:39 UTC
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).

Comment 137 Thomas Weidner 2005-03-30 03:35:28 UTC
I just installed openmotif-2.2.3-r6. i noticed that /usr/lib/opemotif-2.2/ is added to /etc/, why not link /usr/lib/openmotif-2.2/, and 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 138 bartron 2005-03-30 14:39:33 UTC
Comment #136:

Comment 139 bartron 2005-03-30 14:39:33 UTC
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 

Comment #137:
  I'd vote for that too (again).

Comment 140 bartron 2005-03-30 14:50:43 UTC
Comment #136 again:

Comment 141 bartron 2005-03-30 14:50:43 UTC
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.
Comment 142 Tobias D. 2005-04-05 15:48:55 UTC
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.
Comment 143 m.o.e. 2005-04-05 16:26:16 UTC
Interesting. Is there a chance to get the old behaviour back before the new
ebuilds go stable? This ain't very convenient.
Comment 144 bartron 2005-04-05 18:13:43 UTC

Comment 145 bartron 2005-04-05 18:13:43 UTC
  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'...
Comment 146 bartron 2005-04-05 18:57:25 UTC

Comment 147 bartron 2005-04-05 18:57:25 UTC
  Forget my last comment, already been done... bug #86822
Comment 148 bartron 2005-04-05 18:59:54 UTC
Created attachment 55420 [details]
testprogram comment 142
Comment 149 bartron 2005-04-05 18:59:54 UTC
Created attachment 55420 [details]
testprogram comment 142

  (adjust prefixes in Makefile as necessary, `make run' runs with (openmotif-2.2.2), `make run223' runs with (openmotif.2.2.3).
Comment 150 m.o.e. 2005-04-10 19:44:28 UTC
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.
Comment 151 Tobias D. 2005-04-21 17:25:14 UTC
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?
Comment 152 Tobias D. 2005-04-24 15:32:00 UTC
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  '' 
libtool: install: warning: relinking `'                                
(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 -rpath /usr/lib -version-info 2:1 -no-undefined Mrm.lo lookup.lo 
misc.lo ../Xm-2.1/ -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, 
-o .libs/ 

Full logs in the mail shortly.
Comment 153 bartron 2005-04-24 16:17:01 UTC

  In the libtool call `../Xm-2.1/' 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)?
Comment 154 Tobias D. 2005-04-24 16:37:02 UTC
Ha, good catch. Just looked to me like some innocent compiler-internal directory...
dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \
  /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../..// -lfontconfig'

dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \
  /usr/lib/ -lfontconfig'

But shouldn't libtoolize (or elibtoolize in -r2) have corrected that?
Comment 155 bartron 2005-04-24 17:33:51 UTC

Comment 156 bartron 2005-04-24 17:33:51 UTC
  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 with the 1.4.3 version
did the trick).

  So we have two problems here...

(a) libtool "finds" in one of the compiler internal
directories and thinks (by string comparison)




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 `' 
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'...
Comment 157 Reporter 2005-04-24 17:48:51 UTC

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, 
-o .libs/
dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \
  /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../..// -lfontconfig'

dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \
  /usr/lib/ -lfontconfig'


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, 
-o .libs/
dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \
  /usr/lib// -lfontconfig'

dependency_libs=' -L/usr/X11R6/lib -lSM -lICE -lXt -lXp -lXext -lX11 \
  /usr/lib/ -lfontconfig'
Comment 158 bartron 2005-04-24 18:39:26 UTC

Comment 159 bartron 2005-04-24 18:39:26 UTC
  "/usr/lib//" != "/usr/lib/"... sweet.

  I could think of three possible solutions...

(1) Don't install `' (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
Comment 160 Tobias D. 2005-04-24 19:16:08 UTC
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
Comment 161 bartron 2005-04-24 19:33:20 UTC
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/', 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
Comment 162 Tobias D. 2005-04-24 19:54:56 UTC
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.
Comment 163 Reporter 2005-04-24 20:04:16 UTC
EXCELLENT!! Any chance to see this in portage soon?

Comment 164 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-25 03:48:48 UTC
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.
Comment 165 Tobias D. 2005-04-25 19:41:53 UTC
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.
Comment 166 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-26 06:57:07 UTC
ok, new versions in portage, please test
Comment 167 bartron 2005-04-26 17:39:41 UTC
re: comment #157:

Comment 168 bartron 2005-04-26 17:39:41 UTC
re: comment #157:

  openmotif-2.2.3 is affected too... with the included libtool (1.4.3) 
library search order is


After `libtoolize' (libtool updated to 1.5.14) search order becomes


Comment 169 Tobias D. 2005-04-26 21:32:22 UTC
So....could we move on to motif-config?
Comment 170 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-26 21:49:46 UTC
but this order isn't better, is it, since /usr/X11R6/lib is a link to /usr/lib
Comment 171 bartron 2005-04-28 18:20:23 UTC

Comment 172 bartron 2005-04-28 18:20:23 UTC
  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)
Comment 173 bartron 2005-04-28 18:21:21 UTC
  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 in `$FILESDIR' (no dependency on moving target).

(2) Turn off relinking.
Comment 174 Heinrich Wendel (RETIRED) gentoo-dev 2005-04-29 08:28:11 UTC
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?
Comment 175 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-08 09:57:05 UTC
no comments?

seems like the current version of motif-config works as espected, no bug reports yet
Comment 176 m.o.e. 2005-05-10 18:13:30 UTC
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 

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.
Comment 177 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-16 07:39:41 UTC
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?
Comment 178 Tobias D. 2005-05-18 17:07:28 UTC
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?
Comment 179 Heinrich Wendel (RETIRED) gentoo-dev 2005-05-19 06:37:37 UTC
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 
Comment 180 m.o.e. 2005-12-30 20:50:27 UTC

Comment 181 m.o.e. 2005-12-30 20:50:27 UTC
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?
Comment 182 Tobias D. 2005-12-30 21:01:22 UTC
Security fix (sort of).
Comment 183 bartron 2005-12-30 21:15:42 UTC

Comment 184 bartron 2005-12-30 21:15:42 UTC
  Security fix?
Comment 185 Tobias D. 2005-12-30 21:26:27 UTC
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.)
Comment 186 bartron 2005-12-30 21:41:00 UTC

Comment 187 bartron 2005-12-30 21:41:00 UTC
  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.

Comment 188 Tobias D. 2005-12-30 21:55:30 UTC
So, do you want to take over, or should I?
Comment 189 bartron 2005-12-30 22:01:55 UTC

Comment 190 bartron 2005-12-30 22:01:55 UTC
  I'll take it... but let's move that to #114234.
Comment 191 Heinrich Wendel (RETIRED) gentoo-dev 2006-02-14 01:18:00 UTC
this one is done then, only the security left.