I've been using the SeaMonkey built-in HTML editor from the epel repo for CentOS 6.7:
$ repoquery -i seamonkey
Name : seamonkey Version : 2.39 Release : 1.el6 Architecture: x86_64 Size : 127340745 Packager : Fedora Project Group : Applications/Internet URL : http://www.seamonkey-project.org Repository : epel Summary : Web browser, e-mail, news, IRC client, HTML editor Source : seamonkey-2.39-1.el6.src.rpm
This is now dumping core. The latest release, directly from Mozilla (2.9b4), fails with:
/usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Recommendations for alternative HTML editors for this system?
Thanks.
Tim Evans wrote:
I've been using the SeaMonkey built-in HTML editor from the epel repo for CentOS 6.7:
<snip>
This is now dumping core. The latest release, directly from Mozilla (2.9b4), fails with:
/usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Recommendations for alternative HTML editors for this system?
I take it you can't downgrade?
mark "as my own web page reads at the bottom, 'this page proudly built in vi'"
I use kompozer (http://www.kompozer.net/) It's based on the html editor in seamonkey.
Jason
On 27.1.2016 17:15, Tim Evans wrote:
I've been using the SeaMonkey built-in HTML editor from the epel repo for CentOS 6.7:
$ repoquery -i seamonkey
Name : seamonkey Version : 2.39 Release : 1.el6 Architecture: x86_64 Size : 127340745 Packager : Fedora Project Group : Applications/Internet URL : http://www.seamonkey-project.org Repository : epel Summary : Web browser, e-mail, news, IRC client, HTML editor Source : seamonkey-2.39-1.el6.src.rpm
This is now dumping core. The latest release, directly from Mozilla (2.9b4), fails with:
/usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Recommendations for alternative HTML editors for this system?
Thanks.
On 01/27/2016 12:40 PM, J. S. Evans wrote:
I use kompozer (http://www.kompozer.net/) It's based on the html editor in seamonkey.
Thanks.
$ /usr/local/kompozer/kompozer & [1] 1905 /usr/local/kompozer $ ./kompozer-bin: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
This is apparently a 32-bit package, while the referenced lib (which is installed) is 64-bit. Presumably, I'll need to find and install one or more 32-bit lib packages.
Again, this is CentOS 6.7.
On 01/27/2016 02:47 PM, Clint Dilks wrote:
/usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Have you tried yum provides 'libdbus-glib-1.so.2'. I get a hit with dbus-glib
Thanks.
Package dbus-glib-0.86-6.el6.x86_64 already installed and latest version
On 1/27/2016 12:43 PM, Tim Evans wrote:
On 01/27/2016 02:47 PM, Clint Dilks wrote:
/usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Have you tried yum provides 'libdbus-glib-1.so.2'. I get a hit with dbus-glib
Thanks.
Package dbus-glib-0.86-6.el6.x86_64 already installed and latest version
# rpm -ql dbus-glib.x86_64 /usr/bin/dbus-binding-tool /usr/lib64/libdbus-glib-1.so.2 /usr/lib64/libdbus-glib-1.so.2.1.0 /usr/share/doc/dbus-glib-0.86 /usr/share/doc/dbus-glib-0.86/COPYING /usr/share/doc/dbus-glib-0.86/ChangeLog /usr/share/doc/dbus-glib-0.86/NEWS
is seamonkey .i686 or .x86_64 ? you might need to yum install dbus-glib.i686
# yum list dbus-glib* ..... Installed Packages dbus-glib.x86_64 0.86-6.el6 @UIedited_0/6.5 Available Packages dbus-glib.i686 0.86-6.el6 base dbus-glib-devel.i686 0.86-6.el6 base dbus-glib-devel.x86_64 0.86-6.el6 base
On 01/27/2016 04:17 PM, John R Pierce wrote:
is seamonkey .i686 or .x86_64 ? you might need to yum install dbus-glib.i686
Thanks.
$ rpm -aq seamonkey seamonkey-2.39-1.el6.x86_64
Double-check:
$ file /usr/lib64/seamonkey/seamonkey-bin /usr/lib64/seamonkey/seamonkey-bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped
$ uname -a Linux osprey 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 21:19:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
On 01/27/2016 04:59 PM, Clint Dilks wrote:
What is the result of ldd /usr/lib64/seamonkey/seamonkey-bin
# ldd /usr/lib64/seamonkey/seamonkey-bin linux-vdso.so.1 => (0x00007ffe525fc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d6b400000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003d6bc00000) librt.so.1 => /lib64/librt.so.1 (0x0000003d6c000000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003d71c00000) libm.so.6 => /lib64/libm.so.6 (0x0000003d6b800000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003d71800000) libc.so.6 => /lib64/libc.so.6 (0x0000003d6b000000) /lib64/ld-linux-x86-64.so.2 (0x0000003d6ac00000)
On Thu, Jan 28, 2016 at 11:01 AM, Tim Evans tkevans@tkevans.com wrote:
On 01/27/2016 04:59 PM, Clint Dilks wrote:
What is the result of
ldd /usr/lib64/seamonkey/seamonkey-bin
# ldd /usr/lib64/seamonkey/seamonkey-bin linux-vdso.so.1 => (0x00007ffe525fc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d6b400000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003d6bc00000) librt.so.1 => /lib64/librt.so.1 (0x0000003d6c000000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003d71c00000) libm.so.6 => /lib64/libm.so.6 (0x0000003d6b800000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003d71800000) libc.so.6 => /lib64/libc.so.6 (0x0000003d6b000000) /lib64/ld-linux-x86-64.so.2 (0x0000003d6ac00000)
This looks like all dependencies are met but I noticed something, your first message mentions /usr/local/seamonkey/seamonkey-bin, we are looking at /usr/lib64/seamonkey/seamonkey-bin, which one are you using and do both exist on your system ?
On 01/27/2016 05:11 PM, Clint Dilks wrote:
This looks like all dependencies are met but I noticed something, your first message mentions /usr/local/seamonkey/seamonkey-bin, we are looking at /usr/lib64/seamonkey/seamonkey-bin, which one are you using and do both exist on your system ?
My bad for fogging things up. Besides the epel rpm, I had also tried the (non-rpm) tar file from mozilla of the latest beta release (installed in /usr/local). That turns out to be a 32-bit version. The epel rpm is clearly 64-bit.
My bad for fogging things up. Besides the epel rpm, I had also tried the (non-rpm) tar file from mozilla of the latest beta release (installed in /usr/local). That turns out to be a 32-bit version. The epel rpm is clearly 64-bit.
Well if you are still seeing the same error then the only think I can think of is that elements of your install in /usr/local are conflicting with the RPM version. If you haven't already completely remove the /usr/local/ instance.
On 01/27/2016 11:15 AM, Tim Evans wrote:
I've been using the SeaMonkey built-in HTML editor from the epel repo for CentOS 6.7:
$ repoquery -i seamonkey
Name : seamonkey Version : 2.39 Release : 1.el6 Architecture: x86_64 Size : 127340745 Packager : Fedora Project Group : Applications/Internet URL : http://www.seamonkey-project.org Repository : epel Summary : Web browser, e-mail, news, IRC client, HTML editor Source : seamonkey-2.39-1.el6.src.rpm
This is now dumping core. The latest release, directly from Mozilla (2.9b4), fails with:
/usr/local/seamonkey/seamonkey-bin: error while loading shared libraries: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory
Recommendations for alternative HTML editors for this system?
To close the loop on this, I've been able to get the latest 32-bit beta of Seamonkey (2.9beta4, tar file downloaded directly from mozilla.org, not anyone's RPM) to work, after installing a batch of 32-bit libs and dependencies. Thanks to Clint Dilks and John R. Pierce for a little coaching on identifying the necessary libs.
J.S. Evans suggested kompozer (http://www.kompozer.net/). This turned out to be a 32-bit app as well, but, even after installing a batch of 32-bit libs, it fails to load, and without presenting any error messages at all--just fails.
Thanks, all.