* emacs GUI please help
@ 2011-02-21 23:38 Alex Lai (Scotia Capital)
0 siblings, 0 replies; 3+ messages in thread
From: Alex Lai (Scotia Capital) @ 2011-02-21 23:38 UTC (permalink / raw)
To: help-gnu-emacs@gnu.org
Cc: Andrei Dragalin (Scotia Capital), Quazi Islam (Scotia Capital),
Virgil Rusen (Scotia Capital), Mark Giziewicz (Scotia Capital)
[-- Attachment #1: Type: text/plain, Size: 7420 bytes --]
Hi emacs gurus,
I'm wondering if you would help me with an emacs GUI issue I have recently when I installed emacs 23.2 for use by our financial engineering group.
[Problem]
$ DISPLAY=sbtorsvr329:23.0; export DISPLAY
$ /usr/local/bin/emacs
ld.so.1: emacs: fatal: relocation error: file /usr/local/bin/emacs: symbol rsvg_handle_get_dimensions: referenced symbol not found
Killed
$ DISPLAY=sbdevsvr286.dev:148.0; export DISPLAY
$ /usr/local/bin/emacs --> successful
We use the emacs and dependent packages compiled by sunfreeware.com (SMC* packages) for Solaris 10 sparc.
The problem I have with GUI emacs lauch is that the success depends on the display set. It will launch fine for one display but crash for the other.
As you can see below, when the display is set to sbtorsvr329:23.0, the dynamic linker try to resolve the symbol rsvg_handle_get_dimensions, which is not defined in librsvg-2.so.2 being used, therefore it crashes; however, when the display is set to bdevsvr286.dev:148.0, the dynamic linker never try to resolve that symbol, as such, the GUI successfully gets launched:
--------------------------
$ LD_DEBUG=audit,reloc,symbols
$ DISPLAY=sbtorsvr329:23.0; export DISPLAY
$ /usr/local/bin/emacs 2>emacs.disp=sbtorsvr329:23.0 --> emacs GUI crashed
Killed
$ grep rsvg_handle_get_dimensions emacs.dis=sbtorsvr329:23.0|wc -l
569
$ grep rsvg_handle_get_dimensions emacs.dis=sbtorsvr329:23.0|grep librsvg-2.so.2
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
$ DISPLAY=sbdevsvr286.dev:148.0; export DISPLAY
$ /usr/local/bin/emacs 2>emacs.disp=sbdevsvr286.dev:148.0 --> emacs GUI successfully launched
$ grep rsvg_handle_get_dimensions emacs.disp=sbdevsvr286.dev:148.0
--------------------------
$ ldd /usr/local/bin/emacs|grep librsvg
librsvg-2.so.2 => /usr/lib/librsvg-2.so.2
The above library is installed with SUNWgnome-base-libs package and doesn't contain the definition for symbol rsvg_handle_get_dimensions:
$ ls -l /usr/lib/librsvg*
lrwxrwxrwx 1 root root 18 Oct 17 2006 /usr/lib/librsvg-2.so -> librsvg-2.so.2.5.0
lrwxrwxrwx 1 root root 18 Oct 17 2006 /usr/lib/librsvg-2.so.2 -> librsvg-2.so.2.5.0
-rwxr-xr-x 1 root other 112408 Dec 15 2004 /usr/lib/librsvg-2.so.2.5.0
$ echo $LD_LIBRARY_PATH
/usr/lib:/usr/lib/X11
$ /usr/ccs/bin/nm /usr/lib/librsvg-2.so.2 | grep rsvg_handle_get_dimensions --> return empty
The behaviour that emacs resolve the rsvg_handle_get_dimensions symbol for one display but not for the other is really a mystery for me.
Continuing investigation, if I add path /usr/local/lib before /usr/lib, then the rsvg_handle_get_dimensions error doesn't appear since the librsvg provided by SMClrsvg contains the definition for the symbol, but then, emacs crashes with /usr/local/lib/libgtk-x11-2.0.so.0.1200.0 segmentation fault:
$ LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/lib/X11; export LD_LIBRARY_PATH
$ echo $DISPLAY
sbdevsvr285.dev:148.0
$ ldd /usr/local/bin/emacs|grep svg
librsvg-2.so.2 => /usr/local/lib/librsvg-2.so.2
$ /usr/ccs/bin/nm /usr/local/lib/librsvg-2.so.2 | grep rsvg_handle_get_dimensions
[1594] | 163320| 1144|FUNC |GLOB |0 |13 |rsvg_handle_get_dimensions
$ /usr/local/bin/emacs
GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is not supported
(emacs:19813): Gtk-WARNING **: Conversion from character set '646' to 'UTF-8' is not supported
Fatal error (11)Segmentation Fault
$ mdb /usr/local/bin/emacs
> :r
GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is not supported
(emacs:19831): Gtk-WARNING **: Conversion from character set '646' to 'UTF-8' is not supported
mdb: stop on SIGSEGV
mdb: target stopped at:
libgtk-x11-2.0.so.0.1200.0`gtk_rc_reparse_all_for_settings+0x17c: ld [%o5], %g1
>
For most of the graphics libraries, there are two versions: the native SUNWgnome-base-libs version located in /usr/lib and SMCgtk version from sunfreeware.com located in /usr/local/lib:
$ ls -l /usr/local/lib/libgtk-x11*
-rw-r--r-- 1 bin bin 834 Dec 9 2007 /usr/local/lib/libgtk-x11-2.0.la
lrwxrwxrwx 1 root root 26 Apr 21 2009 /usr/local/lib/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.1200.0
lrwxrwxrwx 1 root root 26 Apr 21 2009 /usr/local/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.1200.0
-rwxr-xr-x 1 bin bin 4823188 Dec 9 2007 /usr/local/lib/libgtk-x11-2.0.so.0.1200.0
$ ls -l /usr/lib/libgtk-x11*
lrwxrwxrwx 1 root root 25 Oct 17 2006 /usr/lib/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.400.9
lrwxrwxrwx 1 root root 25 Oct 17 2006 /usr/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.400.9
-rwxr-xr-x 1 root other 3617016 Dec 1 2009 /usr/lib/libgtk-x11-2.0.so.0.400.9
SMCemacs 23.2 requires SMCgtk 2.12.0, which means the correct version of library was loaded.
I was thinking to try the native libgtk-x11 library, to do this, /usr/lib has been be put before /usr/local/lib, but then it will hit the rsvg_handle_get_dimensions error again.
Can someone please help?
Regards,
Alex Lai
Email: Alex_lai@scotiacapital.com<mailto:Alex_lai@scotiacapital.com>
Tel: (416)6074789
---
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same. No member of the Scotiabank Group is liable for any errors or omissions in the content or transmission of this email or accepts any responsibility or liability for loss or damage arising from the receipt or use of this transmission. Scotiabank Group may monitor, retain and/or review email. Trading instructions received by e-mail or voicemail will not be accepted or acted upon. Unless indicated in writing, opinions contained in this email are those of the author and are not endorsed by any member of the Scotiabank Group.
For information on some members of the Scotiabank Group: http://www.scotiacapital.com/EmailDisclaimer/English_entities.htm
For authorized users of the Scotia Capital trademark: http://www.scotiacapital.com/EmailDisclaimer/English_trademark.htm
Pour obtenir la traduction en français: http://www.scotiacapital.com/EmailDisclaimer/French.htm
Traducción en español: http://www.scotiacapital.com/EmailDisclaimer/Spanish.htm
[-- Attachment #2: Type: text/html, Size: 27078 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <mailman.18.1298381794.4429.help-gnu-emacs@gnu.org>]
* Re: emacs GUI please help
[not found] <mailman.18.1298381794.4429.help-gnu-emacs@gnu.org>
@ 2011-02-22 22:08 ` Tim X
0 siblings, 0 replies; 3+ messages in thread
From: Tim X @ 2011-02-22 22:08 UTC (permalink / raw)
To: help-gnu-emacs
"Alex Lai (Scotia Capital)" <Alex_Lai@scotiacapital.com> writes:
> Hi emacs gurus,
>
>
>
> I’m wondering if you would help me with an emacs GUI issue I have
> recently when I installed emacs 23.2 for use by our financial engineering
> group.
>
>
>
> [Problem]
>
>
>
> $ DISPLAY=sbtorsvr329:23.0; export DISPLAY
>
> $ /usr/local/bin/emacs
> ld.so.1: emacs: fatal: relocation error: file /usr/local/bin/emacs: symbol
> rsvg_handle_get_dimensions: referenced symbol not found
> Killed
>
>
>
> $ DISPLAY=sbdevsvr286.dev:148.0; export DISPLAY
>
> $ /usr/local/bin/emacs à successful
>
>
>
> We use the emacs and dependent packages compiled by sunfreeware.com (SMC*
> packages) for Solaris 10 sparc.
>
> The problem I have with GUI emacs lauch is that the success depends on the
> display set. It will launch fine for one display but crash for the other.
> As you can see below, when the display is set to sbtorsvr329:23.0, the dynamic
> linker try to resolve the symbol rsvg_handle_get_dimensions, which is not
> defined in librsvg-2.so.2 being used, therefore it crashes; however, when the
> display is set to bdevsvr286.dev:148.0, the dynamic linker never try to resolve
> that symbol, as such, the GUI successfully gets launched:
>
>
>
> --------------------------
> $ LD_DEBUG=audit,reloc,symbols
>
> $ DISPLAY=sbtorsvr329:23.0; export DISPLAY
> $ /usr/local/bin/emacs
> 2>emacs.disp=sbtorsvr329:23.0
> à emacs GUI crashed
> Killed
>
> $ grep rsvg_handle_get_dimensions emacs.dis=sbtorsvr329:23.0|wc -l
> 569
> $ grep rsvg_handle_get_dimensions emacs.dis=sbtorsvr329:23.0|grep
> librsvg-2.so.2
> 13815: 1: symbol=rsvg_handle_get_dimensions; lookup in
> file=/usr/lib/librsvg-2.so.2 [ ELF ]
> 13815: 1: symbol=rsvg_handle_get_dimensions; lookup in
> file=/usr/lib/librsvg-2.so.2 [ ELF ]
> 13815: 1: symbol=rsvg_handle_get_dimensions; lookup in
> file=/usr/lib/librsvg-2.so.2 [ ELF ]
> 13815: 1: symbol=rsvg_handle_get_dimensions; lookup in
> file=/usr/lib/librsvg-2.so.2 [ ELF ]
>
> $ DISPLAY=sbdevsvr286.dev:148.0; export DISPLAY
> $ /usr/local/bin/emacs
> 2>emacs.disp=sbdevsvr286.dev:148.0
> à emacs GUI successfully launched
>
> $ grep rsvg_handle_get_dimensions emacs.disp=sbdevsvr286.dev:148.0
> --------------------------
>
>
>
> $ ldd /usr/local/bin/emacs|grep librsvg
> librsvg-2.so.2 => /usr/lib/librsvg-2.so.2
>
>
>
> The above library is installed with SUNWgnome-base-libs package and doesn’t
> contain the definition for symbol rsvg_handle_get_dimensions:
>
>
>
> $ ls -l /usr/lib/librsvg*
> lrwxrwxrwx 1 root root 18 Oct 17 2006 /usr/lib/librsvg-2.so ->
> librsvg-2.so.2.5.0
> lrwxrwxrwx 1 root root 18 Oct 17 2006 /usr/lib/librsvg-2.so.2
> -> librsvg-2.so.2.5.0
> -rwxr-xr-x 1 root other 112408 Dec 15 2004
> /usr/lib/librsvg-2.so.2.5.0
>
>
>
> $ echo $LD_LIBRARY_PATH
> /usr/lib:/usr/lib/X11
>
>
>
> $ /usr/ccs/bin/nm /usr/lib/librsvg-2.so.2 | grep
> rsvg_handle_get_dimensions à return
> empty
>
>
>
>
>
> The behaviour that emacs resolve the rsvg_handle_get_dimensions symbol for one
> display but not for the other is really a mystery for me.
>
>
>
> Continuing investigation, if I add path /usr/local/lib before /usr/lib, then
> the rsvg_handle_get_dimensions error doesn't appear since the librsvg provided
> by SMClrsvg contains the definition for the symbol, but then, emacs crashes
> with /usr/local/lib/libgtk-x11-2.0.so.0.1200.0 segmentation fault:
>
>
>
> $ LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/lib/X11; export LD_LIBRARY_PATH
> $ echo $DISPLAY
> sbdevsvr285.dev:148.0
>
>
>
> $ ldd /usr/local/bin/emacs|grep svg
>
> librsvg-2.so.2 => /usr/local/lib/librsvg-2.so.2
>
>
>
> $ /usr/ccs/bin/nm /usr/local/lib/librsvg-2.so.2 | grep
> rsvg_handle_get_dimensions
>
> [1594] | 163320| 1144|FUNC |GLOB |0 |13
> |rsvg_handle_get_dimensions
>
>
> $ /usr/local/bin/emacs
> GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is
> not supported
>
> (emacs:19813): Gtk-WARNING **: Conversion from character set '646' to 'UTF-8'
> is not supported
> Fatal error (11)Segmentation Fault
>
> $ mdb /usr/local/bin/emacs
>> :r
> GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is
> not supported
>
> (emacs:19831): Gtk-WARNING **: Conversion from character set '646' to 'UTF-8'
> is not supported
> mdb: stop on SIGSEGV
> mdb: target stopped at:
> libgtk-x11-2.0.so.0.1200.0`gtk_rc_reparse_all_for_settings+0x17c:
> ld [%o5], %g1
>>
>
>
>
> For most of the graphics libraries, there are two versions: the native
> SUNWgnome-base-libs version located in /usr/lib and SMCgtk version from
> sunfreeware.com located in /usr/local/lib:
>
>
>
> $ ls -l /usr/local/lib/libgtk-x11*
> -rw-r--r-- 1 bin bin 834 Dec 9 2007
> /usr/local/lib/libgtk-x11-2.0.la
> lrwxrwxrwx 1 root root 26 Apr 21 2009
> /usr/local/lib/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.1200.0
> lrwxrwxrwx 1 root root 26 Apr 21 2009
> /usr/local/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.1200.0
> -rwxr-xr-x 1 bin bin 4823188 Dec 9 2007
> /usr/local/lib/libgtk-x11-2.0.so.0.1200.0
>
>
>
> $ ls -l /usr/lib/libgtk-x11*
> lrwxrwxrwx 1 root root 25 Oct 17 2006
> /usr/lib/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.400.9
> lrwxrwxrwx 1 root root 25 Oct 17 2006
> /usr/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.400.9
> -rwxr-xr-x 1 root other 3617016 Dec 1 2009
> /usr/lib/libgtk-x11-2.0.so.0.400.9
>
>
>
> SMCemacs 23.2 requires SMCgtk 2.12.0, which means the correct version
> of library was loaded.
>
>
>
> I was thinking to try the native libgtk-x11 library, to do this, /usr/lib has
> been be put before /usr/local/lib, but then it will hit the
> rsvg_handle_get_dimensions error again.
>
>
>
> Can someone please help?
>
This all looks very odd. It has been many years since I've worked under
Solaris/SunOS, but if your workstations are correctly configured, you
should not need to set the display variable - this should happen
automatically when things are configured correctly as part of the X
login process.
Do you get the same results when running something like hostname --fqdn
on the different machines i.e. a fully qualified domain name
(host.domain.com etc)?
Are you running emacs on the central server with client workstations
connecting to the server and then running emacs? Are all these
workstations runnig the same OS? How are you determining the hostname
part of the display? How are you determining the display number? Can you
run other X applications with the display setting that appears to fail
with emacs?
My guess is that it isn't that emacs cannot load the necessary
libraries, but rather it cannot connect to the X display you have set
and therefore cannot obtain the necessary display parameters and bombs
out (remember that with X, the display information relates to the local
workstation, not the host running emacs). Running another X apps, such
as xload, may provide more details.
Tim
--
tcross (at) rapttech dot com dot au
^ permalink raw reply [flat|nested] 3+ messages in thread
* emacs GUI please help
@ 2011-02-21 23:36 Alex Lai (Scotia Capital)
0 siblings, 0 replies; 3+ messages in thread
From: Alex Lai (Scotia Capital) @ 2011-02-21 23:36 UTC (permalink / raw)
To: help-gnu-emacs@gnu.org
Cc: Andrei Dragalin (Scotia Capital), Quazi Islam (Scotia Capital),
Mark Giziewicz (Scotia Capital)
[-- Attachment #1: Type: text/plain, Size: 7420 bytes --]
Hi emacs gurus,
I'm wondering if you would help me with an emacs GUI issue I have recently when I installed emacs 23.2 for use by our financial engineering group.
[Problem]
$ DISPLAY=sbtorsvr329:23.0; export DISPLAY
$ /usr/local/bin/emacs
ld.so.1: emacs: fatal: relocation error: file /usr/local/bin/emacs: symbol rsvg_handle_get_dimensions: referenced symbol not found
Killed
$ DISPLAY=sbdevsvr286.dev:148.0; export DISPLAY
$ /usr/local/bin/emacs --> successful
We use the emacs and dependent packages compiled by sunfreeware.com (SMC* packages) for Solaris 10 sparc.
The problem I have with GUI emacs lauch is that the success depends on the display set. It will launch fine for one display but crash for the other.
As you can see below, when the display is set to sbtorsvr329:23.0, the dynamic linker try to resolve the symbol rsvg_handle_get_dimensions, which is not defined in librsvg-2.so.2 being used, therefore it crashes; however, when the display is set to bdevsvr286.dev:148.0, the dynamic linker never try to resolve that symbol, as such, the GUI successfully gets launched:
--------------------------
$ LD_DEBUG=audit,reloc,symbols
$ DISPLAY=sbtorsvr329:23.0; export DISPLAY
$ /usr/local/bin/emacs 2>emacs.disp=sbtorsvr329:23.0 --> emacs GUI crashed
Killed
$ grep rsvg_handle_get_dimensions emacs.dis=sbtorsvr329:23.0|wc -l
569
$ grep rsvg_handle_get_dimensions emacs.dis=sbtorsvr329:23.0|grep librsvg-2.so.2
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
13815: 1: symbol=rsvg_handle_get_dimensions; lookup in file=/usr/lib/librsvg-2.so.2 [ ELF ]
$ DISPLAY=sbdevsvr286.dev:148.0; export DISPLAY
$ /usr/local/bin/emacs 2>emacs.disp=sbdevsvr286.dev:148.0 --> emacs GUI successfully launched
$ grep rsvg_handle_get_dimensions emacs.disp=sbdevsvr286.dev:148.0
--------------------------
$ ldd /usr/local/bin/emacs|grep librsvg
librsvg-2.so.2 => /usr/lib/librsvg-2.so.2
The above library is installed with SUNWgnome-base-libs package and doesn't contain the definition for symbol rsvg_handle_get_dimensions:
$ ls -l /usr/lib/librsvg*
lrwxrwxrwx 1 root root 18 Oct 17 2006 /usr/lib/librsvg-2.so -> librsvg-2.so.2.5.0
lrwxrwxrwx 1 root root 18 Oct 17 2006 /usr/lib/librsvg-2.so.2 -> librsvg-2.so.2.5.0
-rwxr-xr-x 1 root other 112408 Dec 15 2004 /usr/lib/librsvg-2.so.2.5.0
$ echo $LD_LIBRARY_PATH
/usr/lib:/usr/lib/X11
$ /usr/ccs/bin/nm /usr/lib/librsvg-2.so.2 | grep rsvg_handle_get_dimensions --> return empty
The behaviour that emacs resolve the rsvg_handle_get_dimensions symbol for one display but not for the other is really a mystery for me.
Continuing investigation, if I add path /usr/local/lib before /usr/lib, then the rsvg_handle_get_dimensions error doesn't appear since the librsvg provided by SMClrsvg contains the definition for the symbol, but then, emacs crashes with /usr/local/lib/libgtk-x11-2.0.so.0.1200.0 segmentation fault:
$ LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/lib/X11; export LD_LIBRARY_PATH
$ echo $DISPLAY
sbdevsvr285.dev:148.0
$ ldd /usr/local/bin/emacs|grep svg
librsvg-2.so.2 => /usr/local/lib/librsvg-2.so.2
$ /usr/ccs/bin/nm /usr/local/lib/librsvg-2.so.2 | grep rsvg_handle_get_dimensions
[1594] | 163320| 1144|FUNC |GLOB |0 |13 |rsvg_handle_get_dimensions
$ /usr/local/bin/emacs
GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is not supported
(emacs:19813): Gtk-WARNING **: Conversion from character set '646' to 'UTF-8' is not supported
Fatal error (11)Segmentation Fault
$ mdb /usr/local/bin/emacs
> :r
GLib: Cannot convert message: Conversion from character set 'UTF-8' to '646' is not supported
(emacs:19831): Gtk-WARNING **: Conversion from character set '646' to 'UTF-8' is not supported
mdb: stop on SIGSEGV
mdb: target stopped at:
libgtk-x11-2.0.so.0.1200.0`gtk_rc_reparse_all_for_settings+0x17c: ld [%o5], %g1
>
For most of the graphics libraries, there are two versions: the native SUNWgnome-base-libs version located in /usr/lib and SMCgtk version from sunfreeware.com located in /usr/local/lib:
$ ls -l /usr/local/lib/libgtk-x11*
-rw-r--r-- 1 bin bin 834 Dec 9 2007 /usr/local/lib/libgtk-x11-2.0.la
lrwxrwxrwx 1 root root 26 Apr 21 2009 /usr/local/lib/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.1200.0
lrwxrwxrwx 1 root root 26 Apr 21 2009 /usr/local/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.1200.0
-rwxr-xr-x 1 bin bin 4823188 Dec 9 2007 /usr/local/lib/libgtk-x11-2.0.so.0.1200.0
$ ls -l /usr/lib/libgtk-x11*
lrwxrwxrwx 1 root root 25 Oct 17 2006 /usr/lib/libgtk-x11-2.0.so -> libgtk-x11-2.0.so.0.400.9
lrwxrwxrwx 1 root root 25 Oct 17 2006 /usr/lib/libgtk-x11-2.0.so.0 -> libgtk-x11-2.0.so.0.400.9
-rwxr-xr-x 1 root other 3617016 Dec 1 2009 /usr/lib/libgtk-x11-2.0.so.0.400.9
SMCemacs 23.2 requires SMCgtk 2.12.0, which means the correct version of library was loaded.
I was thinking to try the native libgtk-x11 library, to do this, /usr/lib has been be put before /usr/local/lib, but then it will hit the rsvg_handle_get_dimensions error again.
Can someone please help?
Regards,
Alex Lai
Email: Alex_lai@scotiacapital.com<mailto:Alex_lai@scotiacapital.com>
Tel: (416)6074789
---
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this email in error, please contact the sender immediately by return electronic transmission and then immediately delete this transmission, including all attachments, without copying, distributing or disclosing same. No member of the Scotiabank Group is liable for any errors or omissions in the content or transmission of this email or accepts any responsibility or liability for loss or damage arising from the receipt or use of this transmission. Scotiabank Group may monitor, retain and/or review email. Trading instructions received by e-mail or voicemail will not be accepted or acted upon. Unless indicated in writing, opinions contained in this email are those of the author and are not endorsed by any member of the Scotiabank Group.
For information on some members of the Scotiabank Group: http://www.scotiacapital.com/EmailDisclaimer/English_entities.htm
For authorized users of the Scotia Capital trademark: http://www.scotiacapital.com/EmailDisclaimer/English_trademark.htm
Pour obtenir la traduction en français: http://www.scotiacapital.com/EmailDisclaimer/French.htm
Traducción en español: http://www.scotiacapital.com/EmailDisclaimer/Spanish.htm
[-- Attachment #2: Type: text/html, Size: 27068 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-02-22 22:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-21 23:38 emacs GUI please help Alex Lai (Scotia Capital)
[not found] <mailman.18.1298381794.4429.help-gnu-emacs@gnu.org>
2011-02-22 22:08 ` Tim X
-- strict thread matches above, loose matches on Subject: below --
2011-02-21 23:36 Alex Lai (Scotia Capital)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).