Re: unicode merge failures 2007-10-12

[James Cloos]

>>>>> "Dan" == Dan Nicolaescu <address@hidden> writes:

(My mx is pathetically behind in spam filtering, so I just saw this,
and have not yet seen any replies which may have been sent....)

Dan> Does anyone else see a too big data segment size for the unicode-2
Dan> binary:

Dan> size -f objs-HEAD/src/emacs objs-unicode-2/src/emacs
Dan>    text    data     bss     dec     hex filename
Dan> 1534480 4031660       0 5566140  54eebc objs-HEAD/src/emacs
Dan> 1656770 11663100      0 13319870 cb3ebe objs-unicode-2/src/emacs

I don't have the compile trees for these two versions around, but on my
(Gentoo) laptop I get:

,----< :; size /usr/bin/emacs-23-unicode >
|    text      data  bss       dec     hex  filename
| 1645849  11526540    0  13172389  c8fea5  /usr/bin/emacs-23-unicode
`----

and on my (Debian) server I get:

,----< :; size /usr/bin/emacs-snapshot-nox >
|    text     data  bss      dec     hex  filename
| 1154944  4054840    0  5209784  4f7eb8  /usr/bin/emacs-snapshot-nox
`----

They are not exactly comparable, since the latter lacks GUI support,
but are about the same as you saw.

My laptop's emacs is compiled --with-x-toolkit=athena --without-gtk,
and was last compiled on September 20, so the data size difference is
not new.

It may be the result of the font backend work.  Does HEAD use 32 bit
ints for all characters in the buffers?  Might strings take up more
space now that they are stored in (modified) UTF-32?  (Just guesses.)

-JimC
-- 
James Cloos <address@hidden>         OpenPGP: 1024D/ED7DAEA6