bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17771: 24.3.91; SIGSEGV in cleanup_vector


From: Stephen Berman
Subject: bug#17771: 24.3.91; SIGSEGV in cleanup_vector
Date: Wed, 18 Jun 2014 15:50:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.91 (gnu/linux)

On Tue, 17 Jun 2014 22:11:43 +0400 Dmitry Antipov <dmantipov@yandex.ru> wrote:

> On 06/17/2014 05:41 PM, Stephen Berman wrote:
>
>> With fontconfig-debuginfo installed I get this:
>>
>>      33.61%    emacs  libc-2.18.so                   [.] __strchr_sse2
>>      15.77%    emacs  libfontconfig.so.1.8.0         [.] 
>> FcStrCaseWalkerNext.part.3
>
> OK. Next steps probably are:
>
> 1) Compile with '--with-x-toolkit=lucid --without-xft'
>    and check how fast HELLO is displayed.

This failed to compile:

/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: 
image.o: undefined reference to symbol 'png_set_longjmp_fn@@PNG16_0'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: 
note: 'png_set_longjmp_fn@@PNG16_0' is defined in DSO /usr/lib64/libpng16.so.16 
so try adding it to the linker command line
/usr/lib64/libpng16.so.16: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make[1]: Leaving directory `/data/steve/lib/emacs/emacs-24.4-lucid/src'
make: *** [src] Error 2

I have both libpng16 and libpng12 installed, since each is required by
different programs I use.  Emacs built with Gtk+ links with libpng16
(which gtk3 requires), but with Lucid it apparently links with libpng12
if installed.  It would be a PITA to uninstall libpng12 just to test
this.  However, when I add `--without-png' to the configure line, then
Emacs with Lucid and without xft successfully builds.  And with this
build it takes only about 3 seconds for HELLO to be displayed (with the
characters for which no suitable font could be found displayed as boxes
containing the hex codepoint).

Then I built with gtk3 and without xft, and here, too, it takes only
about 3 seconds for HELLO to be displayed.

> 2) Identify all font packages installed. I don't know about SuSE,
>    but on my Fedora system all font packages are under 'User Interface/X'
>    group, so "rpm -q -g 'User Interface/X'" shows all font packages
>    (plus other X stuff, which may be filtered out by grepping for "noarch"
>     packages). On my system, the following command:
>
>    rpm -q -g 'User Interface/X' | grep noarch | grep font | wc -l
>
>    shows 84 font packages.
>
> 3) Save list of packages obtained at step 2) and try to uninstall the most
>    of font packages (but do not touch X core fonts - xorg-x11-fonts-* packages
>    on my system). Next try to run "regular" (with Xft support enabled) Emacs
>    and check whether font removal helps to speedup C-h h.
>
> 4) Reinstall all required fonts.

I took the opposite route, which was easier for me: I installed font
packages for all the languages that were displayed as hex codepoint
boxes (mainly South Asia and South East Asia).  And lo and behold, now
with my normal build (including Xft support), it also takes only about 3
seconds for HELLO to be displayed (and there are no more hex codepoint
boxes)!

Prior to this, I had installed font packages for all languages in HELLO,
but still some characters in Tibetan were only displayed as hex
codepoint boxes.  And it still took 30+ seconds for HELLO to be
displayed.  But I found another font package for Tibetan which contained
the missing characters, and that made the difference.  So probably the
lag was just due the searching through all fonts, as Andreas said.

Steve Berman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]