Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 31205 - Opera 7.2x ebuilds still depend on lesstif
Summary: Opera 7.2x ebuilds still depend on lesstif
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Heinrich Wendel (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-15 08:45 UTC by Sven
Modified: 2003-10-18 18:01 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven 2003-10-15 08:45:27 UTC
Since 7.20beta7 Opera comes with a file called operamotifwrapper-3 which is
linked against libXm.so.3 instead of libXm.so.2 like the file operamotifwrapper
which is used by default. Simply replace the file operamotifwrapper with the
newer version.

Reproducible: Always
Steps to Reproduce:
emerge openmotif
emerge opera >=7.20beta7
try to get it working without emerging lesstif
Actual Results:  
opera ebuild depends on lesstif

Expected Results:  
opera ebuild should depend on latter versions of openmotif instead of lesstif

in the new ebuilds, there should perhaps be a note, that lesstif can be unmerged
if opera was the only reason to install lesstif
Comment 1 bartron 2003-10-15 19:34:32 UTC
  I'd consider this a bug in opera...
  
  In opera-7.21, `operamotifwrapper' still appears to be linked 
with a lesstif libXm.so.2 (which is *not* provided by any 
distribution I've checked -- although two comments in another 
bug claim it also to be working with openmotif-2.1...except 
for the size mismatch warning for one of the exported symbols 
at startup).

  The alternative, `operamotifwrapper-3', links to libXm.so.3 
(openmotif-2.2), but is refered to as `operamotifwrapper.3' 
in the install script...
Comment 2 Sven 2003-10-15 22:52:51 UTC
even if the file is called openmotifwrapper.3 - Opera will not use it automatically
and the install.sh doesn't check for libXm.so.3, it just copies the file.
We have to copy the libXm.so.3 version of the wrapper over the libXm.so.2
version.
Comment 3 bartron 2003-10-16 16:43:04 UTC
  No...it's the other way around. `install.sh' should check for
`operamotifwrapper-3' and install it under that name. From looking 
at `libnpp.so' in a debugger, it tries to load the wrapper under 
these names in that order:

    operamotifwrapper
    operamotifwrapper-1
    operamotifwrapper-2
    operamotifwrapper-3
    operamotifwrapper-4

and uses the first that loads successfully.  It is reported to 
work when using the RH9 rpm (on RH9) with only libXm.so.2, 
libXm.so.3, or both installed.  Only difference is in RH9 is,
`operamotifwrapper' is installed as `operamotifwrapper-2'.

Comment 4 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-17 03:19:42 UTC
i fixed the dep in the ebuild, if openmotif-2.2* is installed, it will install
operamotifwrapper-3
Comment 5 Sven 2003-10-17 11:37:29 UTC
@bartron:
I renamed operamotifwrapper to operamotifwrapper-2 and it didn't help.
Opera loads operamotifwrapper-2 and that fails. I can see the error on the
console.

@lanius:
The new 7.21 ebuild still doesn't install operamotifwrapper-3 like it should
(i saw the cp-command etc in the ebuild). Opera still fails loading libXm.so.2
Comment 6 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-17 11:39:19 UTC
emerge -s motif
emerge -s lesstif
Comment 7 Sven 2003-10-17 11:45:41 UTC
lesstif is not install
x11-libs/openmotif-2.2.2-r1 is installed.

BTW: i read the ebuild-script and i know that it should detect that openmotif-2.2*
is installed - but it doesn't work, i don't know why.
Comment 8 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-17 12:20:14 UTC
a little syntax error, finally fixed :)
Comment 9 bartron 2003-10-18 17:59:33 UTC
[small addition to comment #3]

  Hm...seems I can't reproduce said RedHat behavior either,
my mistake...should have checked it myself.  What libnpp does
is, it fork()'s, then the new process tries to exec() 
operamotifwrapper with the names mentioned above until execve() 
does not return.  Of course, when it comes to loading shared 
libraries *inside* the child, it's already too late to do that... 
and I have *NO* idea how the observed behavior is supposed to work 
on RedHat.

  Although I kind of like this kind of flexibility.  Just some
thought...if `operamotifwrapper' is installed as `operamotifwrapper-2',
`operamotifwrapper' could be a small script that that checks 
which `libXm' is available at the time it is invoked:

----begin operamotifwrapper----
#!/bin/bash
if [ -f "/usr/lib/libXm.so.2" -o -f "/usr/X11R6/lib/libXm.so.2" ]; then
    exec $plugdir/operamotifwrapper-2 "$@"
else
    exec $plugdir/operamotifwrapper-3 "$@"
fi
----end operamotifwrapper----
Comment 10 bartron 2003-10-18 18:01:45 UTC
Suggested patch to `opera-7.21.ebuild'

    # install correct motifwrapper
-    if has_version '=x11-libs/openmotif-2.2*'; then
-        rm ${D}/opt/opera/lib/opera/plugins/operamotifwrapper
-        cp ${S}/plugins/operamotifwrapper-3 ${D}/opt/opera/lib/opera/plugins
-    fi
+    mv "${D}/opt/opera/lib/opera/plugins/operamotifwrapper" \
+       "${D}/opt/opera/lib/opera/plugins/operamotifwrapper-2"
+    cp "${S}/plugins/operamotifwrapper-3" \
+       "${D}/opt/opera/lib/opera/plugins"
+    cat <<EOT >"${D}/opt/opera/lib/opera/plugins/operamotifwrapper"
+#!/bin/bash
+if [ -f "/usr/lib/libXm.so.2" -o -f "/usr/X11R6/lib/libXm.so.2" ]; then
+    exec \${0%/*}/operamotifwrapper-2 "\$@"
+else
+    exec \${0%/*}/operamotifwrapper-3 "\$@"
+fi
+EOT
+    chmod +x "${D}/opt/opera/lib/opera/plugins/operamotifwrapper"
+