calendar window fits no more in 80 cols
26 years
Giacomo Boffi
Giacomo Boffi
Context:
- (insert (emacs-version)) XEmacs 21.2 (beta19) "Shinjuku" [Lucid]
(i586-pc-linux) of Tue Sep 28 1999 on boffi95.stru.polimi.it
- (insert (calendar-version)) Version 6, October 12, 1995
------------------------------------------------------------------------
the standard (3 months) calendar window fits no more in a XEmacs frame
that's 81 cols wide (i guess it wouldnt fit in a 80 cols wide, too :-)
ciao
- 1 participants
- 0 comments
Created with XEmacs
26 years
john s jacobs anderson
john s jacobs anderson
I've put up a 'Created with XEmacs' page, similar to the 'Made with
Mac' page at mit.edu. If you have a website where you fly the 'Created
with XEmacs' logo, please send me the URL so I can list you on the
page.
If you have a website and you *aren't* displaying the 'Created with
XEmacs' image, get thee to
<URL:http://www.xemacs.org/About/created.html> and follow the
instructions there. (You _are_ building your sites with XEmacs, right?)
(Any comments on the text on that page are also, of course,
welcome. Once I get a few more sites listed, I'll send off
announcements to ce.xemacs and gnu.announce.)
Thanks,
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)genehack.org Journeyman Molecular Biologist
<URL:http://genehack.org/> <------- GeneHack: bioinfo*linux*opinion
- 2 participants
- 1 comments
XEmacs FTP over HTTP (was Re: XEmacs 21.1.6 for MS Windows is released.)
26 years
Jason R Mastaler
Jason R Mastaler
"Gerhardt, Frank" <frank.gerhardt(a)daimlerchrysler.com> writes:
> Please make XEmacs available also via http download for people
> behind firewalls. Thank you.
You can now access the XEmacs FTP tree through HTTP at:
<http://ftp.xemacs.org/pub/xemacs/>
Simply replace ftp:// with http:// to get the HTTP version
of a FTP URL.
Enjoy.
- 1 participants
- 0 comments
Re: FAQ status
26 years
john s jacobs anderson
john s jacobs anderson
>>>>> "JV" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
JV> john s jacobs anderson <jacobs(a)azstarnet.com> writes:
>> FWIW, about 25% to 50% of my 'XEmacs-time' is being spent
>> answering/re-directing support mails that come into the
>> webmaster(a)xemacs.org address -- does this seem right?
JV> No. IMHO all those question should go to
JV> comp.xemacs.emacs. However there seem to be too few people who
JV> actually answer problems there. I find myself spending more
JV> time answering problems there than I actually want too. (The
JV> same would hold for all the other emacs groups if it weren't
JV> for Kai Grossjohan)
Both you and Kai deserve *major* thanks for the work you do keeping
high signal:noise in the emacs groups. I'd be pitching in more, but
for time and (perceived) inexperience. I will start trying to do a bit
more; at least reading more of the feed should help with the latter
problem (although not the former, alas!).
I agree that support mails shouldn't be directed to
webmaster(a)xemacs.org, but I have been taking a stab at answering
questions, and directing people to ce.xemacs for followup. I guess
I'll write a form letter directing people to mailing lists and
ce.xemacs, and start using that instead of personalized replies - it
should save a little time.
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)genehack.org Journeyman Molecular Biologist
<URL:http://genehack.org/> <------- GeneHack: bioinfo*linux*opinion
- 1 participants
- 0 comments
Re: TPD, here we go again
26 years
Jan Vroonhof
Jan Vroonhof
Olivier Galibert <galibert(a)pobox.com> writes:
> > - How have you addressed the problem of the mark phase of GC writing
> > to the file?
>
> That's what I'm working on right now: using an external hash table for
> marking instead of an internal markbit.
Ok.. As you are the last person to look in depth at it: How difficult
would it be to implement a write barrier? That would make it possible
to make a non-copying incremental garbage collector (for this you need
3 colors instead of 1 bit for the garbage collector).
In the memory pool idea you would most likely look up the page
the object is in the hash table to get an array and then use the
offset in the page as an array. That way you could make the
set-mark-bit operation independent of the type. i.e.
[... woops.. I got carried away. code at end ]
are using something like that?
> > There is no fundamental reason that would make that impossible. The
> only problem is that a fully running XEmacs includes a bunch of things
> we definitively don't want to try to dump, like devices or buffers.
> We would somehow have to avoid them, which is not easy if they have
> symbols pointing to them.
I was thinking of a "--naked" argument that makes it behaves like temacs.
[here is that code (generalisation well_known bitarray code]
/* set_object-color takes the adress of a lisp object and sets is
garbage color. Currently only two colors are used: Marked and
unmarked. */
/* One must make sure the tables exist for each page with objects to allow
these functions to be fast and small */
/* Note I assume that all objects are at least 8 bytes big
and aligned on multibles on 8. This holds true for all current
lcrecord types. I propose to implement all other types as
struct {
lrecord_header type_desc; /* 32 bits */
*void real_data; } generic_lisp_object;
This needs to be a union for ANSI.
That means you can start by making the type pools pages of
generic_lisp_object and the type check becomes
page_type ( page_for_object(obj) ) == GENERIC &&
lheader_type (((generic_lisp_object *)obj)->type_desc) == the_type
*/
#define MINOBJALIGN 8
/* implementation for a typical 32 bit machine */
#define PAGESIZE 4096
#define OBJPERPAGE (PAGESIZE/MINOBJALIGN)
#define PAGEMASK 0xFFFFF000
#define FULLWORD_MASK 0xFFFF
typedef enum {umarked = 0, marked = 1} gccolors;
#define NR_GCCOLBITS 1
#define GCCOL_MASK 0x00000001
#define GCCOLS_PER_WORD (32 / NR_GCCOLBITS)
#define GC_WORDSPERPAGE (OBJPERPAGE / GCCOLS_PER_WORD)
typedef unsigned int gccol_word_t
typedef gccol_word_t[OBJPERPAGE] gccol_page_t
static inline addr_t page_for_object (LispObject obj)
{
return ((addr_t) obj) / PAGESIZE;
}
static inline unsigned offset_for_object (LispObject obj)
{
return (((addr_t) obj) % PAGESIZE) / MINOBJALIGN;
}
static inline *gccol_page_t
colorpage_for_page (addr_t page)
{
return (*gccol_page_t) hash_lookup (gccol_hashtable, (unsigned)page);
}
inline void
set_object_gccolor (LispObj obj, gccolors color)
{
*gccol_page_t colors = colorpage_for_page (page_for_object (obj));
unsigned offset = offset_for_object(obj);
unsigned shift = offset % GCCOLS_PER_WORD;
*gccol_word word = &(colors[offset / GCCOLS_PER_WORD]);
*word = (*word & ((FULLWORDMASK - GCCOL_MASK) << shift))
+ color << shift;
}
inline gccolors
get_object_gccolor (LispObj obj)
{
*gccol_page_t colors = colorpage_for_page (page_for_object (obj));
unsigned offset = offset_for_object(obj);
unsigned shift = offset % GCCOLS_PER_WORD;
gccol_word word = (colors[offset / GCCOLS_PER_WORD]);
return (word >> shift) & GCCOL_MASK;
}
- 1 participants
- 0 comments
Re: TPD, here we go again
26 years
Jan Vroonhof
Jan Vroonhof
Olivier Galibert <galibert(a)pobox.com> writes:
> 3. Remaining issues
>
> The build process will have to start a post-dump xemacs, ask it the
> loading address (which will, hopefully, be always the same between
> different xemacs invocations) and relocate the file to the new
> address. This way the object relocation phase will not have to be
> done, which means no writes in the objects and that, because of the
> use of mmap, the dumped data will be shared between all the xemacs
> running on the computer.
Some questions
- How have you addressed the problem of the mark phase of GC writing
to the file?
- How flexible is this with regard to the in memory representation of
objects. In particular using a typed pool allocator as I suggested a
while back to reduce the memory overhead of using l[c]records for
everything. I still think 50% memory overhead is a lot.
- Would it be possible for an xemacs to 're-pdump' itself? In particular
it would be nice to be able to re-pdump XEmacs after every package
upgrade and thus avoid the package scanning altogether. For this be
feasible the pdumping needs to be robust and be possible from the
distributed binary.
Jan
- 2 participants
- 1 comments
Re: FAQ status
26 years
Jan Vroonhof
Jan Vroonhof
john s jacobs anderson <jacobs(a)azstarnet.com> writes:
> FWIW, about 25% to 50% of my 'XEmacs-time' is being spent
> answering/re-directing support mails that come into the
> webmaster(a)xemacs.org address -- does this seem right?
No. IMHO all those question should go to comp.xemacs.emacs. However
there seem to be too few people who actually answer problems there.
I find myself spending more time answering problems there than I
actually want too. (The same would hold for all the other emacs groups
if it weren't for Kai Grossjohan)
Of it would be a lot better if our quality control was any better.
21.1.7 seems to have shipped with a broken dumper on linux and we will
still have packages like jka-compr and mule-base that are severely broken.
> What is the status of the FAQ?
I have no idea.
Jan
- 1 participants
- 0 comments
Re: TPD, here we go again
26 years
Olivier Galibert
Olivier Galibert
On Fri, Oct 08, 1999 at 09:04:15PM -0700, Ben Wing wrote:
> Before you get too much farther, is it possible that you could write up a
> basic document describing the design of your portable dumper (for eventual
> inclusion in the XEmacs Internals Manual)?
Ok, lemme write it. Martin and others, please proof-read heavily.
I'm french, after all, english's not my native language, and it's 3 in
the morning ;-)
I wouldn't yell about someone moving things around/rewriting parts if
he fells it makes the document better either.
I've never gotten around learning the texinfo tags, sorry. Questions,
comments, whatever, welcome, of course.
OG.
1. What is dumping and its justification
The C code of XEmacs is only a lisp engine with a lot of built-in
primitives useful to write an editor. The editor itself is written in
Lisp, and represents around 100K lines of code. Loading and executing
the initialisations of all this codes takes a bit a time (five to ten
times the usual startup time of current xemacs) and requires to have
all the lisp source files around. Having to reload them each time the
editor is stardted would not be acceptable.
The traditional solution to this problem is called dumping: the
building process first creates the lisp engine under the name temacs,
then runs it until it has finished loading and initialising all the
lisp part, and eventually creates a new executable called xemacs
including both temacs and all the contents of the memory after the
initialisation.
This solution, while working, has a huge problem: the creation of the
new executable from the actual contents of the memory is a extremely
system-specific process, quite error-prone, and which interferes with
a lot of system librairies (like malloc). It is even getting worse
nowadays with librairies using constructors which are automatically
called when the program is started (even before main()) which tend to
crash when they are called multiple times, once before dumping and
once after (IRIX 6.x libz.so pulls in some C++ image librairies thru
dependencies which have this problem). Writing the dumper is also one
of the most difficult parts of porting XEmacs to a new operating
system.
The aim of the portable dumper is to solve the same problem than the
system-specific dumper, that is the be able to reload quickly and
using a small number of files the fully initialized lisp part of the
editor, without any system-specific hacks.
2. The process
2.1. Overview
The portable dumping system has to:
- at dump time, write all initialized, non quickly rebuildable data to
a file [Note: currently xemacs.dmp, but the name will change], along
with all informations needed for the reloading.
- when starting xemacs, reload the dump file, relocate it to its new
starting address if needed, and reinitialise all pointers to this
data. Also, rebuild all the quickly rebuildable data.
2.2. Data descriptions
The more complex task of the dumper is to be able to write lisp
objects (lrecords) and C structs to disk and reload them at a
different address, updating all the pointers they include in the
process. This is done by using external data descriptions that give
information about the layout of the structures in memory.
The specification of these descriptions is in lrecord.h. A
description for a lrecord is an array of struct lrecord_description.
Each of these structs include a type, an offset in the structure and
some optional parameters depending on the type. For instance, here is
the string description:
static const struct lrecord_description string_description[] = {
{ XD_LISP_OBJECT, offsetof(Lisp_String, plist), 1 },
{ XD_OPAQUE_DATA_PTR, offsetof(Lisp_String, data), XD_INDIRECT(2, 1) },
{ XD_BYTECOUNT, offsetof(Lisp_String, size) },
{ XD_END }
};
The first line means "there is a Lisp_Object at plist in the
Lisp_String structure". The second means "there is a pointer to some
opaque data in the field 'data'". The length of said data is given by
the expression XD_INDIRECT(2, 1), which means "the value in the 3rd
line of the description (line number 2 starting counting at 0, welcome
to C) plus one". The third line indicates a member of type Bytecount,
which is used by the previous indirect directive. XD_END then ends
the description.
This gives all the information we need to move around what is pointed
by a structure (C or lrecord) and, by transitivity, everything that
points to it. The only missing information for dumping is the size of
the structure. For lrecords, this is part of the
lrecord_implementation, hence we do not need to duplicate it. For C
structures we use a struct struct_description, which includes a size
field and a pointer to an associated array of lrecord_description.
2.3. Dumping phase
2.3.1. Start
The dumping is done by calling the function pdump() (in alloc.c) which
is done by Fdump_emacs (in emacs.c). This function does a number of
tasks.
2.3.2. Object inventory
The first task is to build the list of the objects to dump. This
includes:
- lisp objects
- C structures
We end up with one pdump_entry_list_elmt per object group (arrays of C
structs are kept together) which includes a pointer to the first
object of the group, the per-object size and the count of objects in
the group, along with some other informations which are initialised
later.
These entries are linked together in pdump_entry_list structures and
can be enumerated thru either:
- the pdump_object_table, an array of pdump_entry_list, one per
lrecord type, indexed by type number.
- the pdump_opaque_data_list, used for the opaque data which does not
include pointers, and hence does not need descriptions.
- the pdump_struct_table, which is a vector of
struct_description/pdump_entry_list pairs, used for non-opaque C
structures.
This uses a marking strategy similar to the garbage collector. Some
differences though:
- we do not use the mark bit (which does not exist for C structures
anyway), we use a big hash table instead.
- we do not use the mark function of lrecords but instead rely on the
external descriptions. This happens essentially because we need to
follow pointers to C structures and opaque data in addition to
Lisp_Object members.
This is done by pdump_register_object, which handles Lisp_Object
variables, and pdump_register_struct which handles C structures, which
both delegate the description management to pdump_register_sub.
The hashtable doubles as a map object to pdump_entry_list_elmt (i.e,
allows to lookup a pdump_entry_list_elmt with the object it points
to). Entries are added with pdump_add_entry and looked up with
pdump_get_entry. There is no need for entry removal. The hash value
is computed quite basically from the object pointer by
pdump_make_hash.
The roots for the marking are:
- the staticpro'ed variables (there is a special staticpro_nodump call
for protected variables we do not want to dump).
- the pdump_wire'd variables (staticpro is equivalent to
staticpro_nodump + pdump_wire).
- the dumpstruct'ed variables, which points to C structures.
This does not include the GCPRO'ed variables, the specbinds, the
catchtags, the backlist, the redisplay or the profiling info, since we
do not want to rebuild the actual chain of lisp calls which end up to
the dump-emacs call, only the global variables.
Weak lists and weak hash tables are dumped as if they were their
non-weak equivalent (without changing their type, of course). This
has not yet been a problem.
2.3.3. Address allocation
The next step is to allocate the offsets of each of the objects in the
final dump file. This is done by pdump_allocate_offset which is
called indirectly by pdump_scan_by_alignement.
The strategy to deal with alignment problems uses these facts:
- real world alignment requirements are powers of two.
- the C compiler is required to ajust the sizeof of a struct so that
you can have an array of them next to each other. This means you
can have a upper bound of the alignment requirements of a given
structure by looking at which power of two its size is a multiple.
- the non-variant part of variable size lrecords has an alignement
requirement of 4.
Hence, for each lrecord type, C struct type or opaque data block the
alignment requirement is computed as a power of two, with a minimum of
2^2 for lrecords. pdump_scan_by_alignement then scans all the
pdump_entry_list_elmt the ones with the highest requirements first.
This ensures the best compacity.
The maximum alignment requirement we take into account is 2^8.
pdump_allocate_offset only has to do a linear allocation, starting at
offset 256 (this leaves room for the header and keep the alignments
happy).
2.3.4. The header
The next step creates the file and writes a header with a signature
and some random informations in it (number of staticpro, number of
assigned lrecord types, etc...). The reloc_address field, which
indicates at which address the file should be loaded if we want to
avoid post-reload relocation, is set to 0. It then seeks to offset
256 (base offset for the objects).
2.3.5. Data dumping
The data is dumped in the same order the address were allocated by
pdump_dump_data called from pdump_scan_by_alignement. This function
copies the data to a temporary buffer, relocates all pointers in the
object to the addresses allocated in step 2.3.3, and writes it to the
file. Using the same order means that, if we are careful with
lrecords whose size is not a multiple of 4, we are ensured that the
object is always written at the offset in the file allocated in step
2.3.3.
2.3.6. Pointers dumping
A bunch of tables needed to reassign properly the global pointers are
then written. They are:
- the staticpro array
- the dumpstruct array
- the lrecord_implementation table array
- a vector of all the offsets to the objects in the file that include
a description (for faster relocation at reload time)
- the pdump_wired and pdump_wired_list arrays
For each of the arrays we write both the pointer to the variables and
the relocated offset of the object they point to. Since these
variables are global the pointers are still valid when restarting the
program and are used to regenerate the global pointers.
The pdump_wired_list array is a special case. The variable it points
to are the head of weak linked lists of lisp objects of the same type.
Not all objects of this list are dumped so the relocated pointer we
associate with them points to the first dumped object of the list, or
Qnil if none is available. This is also the reason why they are not
used as roots for the purpose of object enumeration.
This is the end of the dumping part.
2.4. Reloading phase
2.4.1. File loading
The file is mmap'ed in memory (which ensures a PAGESIZE alignment, at
least 4096), or if mmap is unavailable or fails a 256-bytes aligned
malloc is done and the file is loaded.
Some variables are reinitialized from the values found in the header.
The difference between the actual loading address and the
reloc_address is computed and will be used for all the relocations.
2.4.2. Putting back the staticvec
The staticvec array is memcpy'd from the file and the variables it
points to are reset to the relocated objects adresses.
2.4.3. Putting back the dumpstructed variables
The variables pointed to by dumpstruct in the dump phase are reset to
the right relocated object addresses.
2.4.4. lrecord_implementations_table
The lrecord_implementations_table is reset to its dump time state and
the right lrecord_type_index values are put in.
2.4.5. Object relocation
All the objects are relocated using their description are their offset
by pdump_reloc_one. This step is unnecessary if the reloc_address is
equal to the file loading address.
2.4.6. Puttin back the pdump_wire and pdump_wire_list variables
Same as 2.4.3.
2.4.7. Reorganize the hash tables
Since some of the hash values in the lisp hash tables are
address-dependant, their layout is now wrong. So we go through each
of them and have them resorted by calling reorganize_hash_table.
3. Remaining issues
The build process will have to start a post-dump xemacs, ask it the
loading address (which will, hopefully, be always the same between
different xemacs invocations) and relocate the file to the new
address. This way the object relocation phase will not have to be
done, which means no writes in the objects and that, because of the
use of mmap, the dumped data will be shared between all the xemacs
running on the computer.
Some executable signature will be necessary to ensure that a given
dump file is really associated with a given executable, or random
crashed will occur. Maybe a random number set at compile or configure
time thru a define. This will also allow for having
differently-compiled xemacsen on the same system (mule and no-mule
comes to mind).
The DOC file contents should probably end up in the dump file.
- 1 participants
- 0 comments
FAQ status
26 years
john s jacobs anderson
john s jacobs anderson
I sent this to the internal XEmacs web maintainers list last week, and
have received no replies. So, I'm now sending it to xemacs-beta and
faq(a)xemacs.org. Any help with the questions below is welcomed.
FWIW, about 25% to 50% of my 'XEmacs-time' is being spent
answering/re-directing support mails that come into the
webmaster(a)xemacs.org address -- does this seem right?
<repost>
What is the status of the FAQ?
Is it still being maintained by Christian Nybø? More importantly, does
mail to faq(a)xemacs.org get answered?
There have been a couple of mails to webmaster(a)xemacs.org in the last
week regarding the contents of the FAQ; I'm unsure what to do with
them. These are the possibilities I've considered, in no particular
order:
(0) send them to faq(a)xemacs.org
(1) ignore them
(2) reply and tell the people not to send support questions to
webmaster(a)xemacs.org.
(3) point them at a non-FAQ resource, like the newsgroup or the
mailing lists.
Any suggestions to this specifically, or the more general problem of
support emails to webmaster(a)xemacs.org are welcome.
Additionally, any news on the FAQ and/or FAQ maintainer's status would
be cool too.
john.
--
------------------------------------------------------------------------
John S Jacobs Anderson Apprentice Geek
jacobs(a)genehack.org Journeyman Molecular Biologist
<URL:http://genehack.org/> <------- GeneHack: bioinfo*linux*opinion
- 1 participants
- 0 comments
segfault in Gnus
26 years
Kai Haberzettl
Kai Haberzettl
Latest 21.2 CVS crashes 100% reproducible when I try to enter a mail-group
in Gnus. xemacs -nw in console or xterm runs fine.
C stack backtrace:
(gdb) run
Starting program: /usr/local/bin/xemacs
Program received signal SIGSEGV, Segmentation fault.
0x81cadc0 in x_finalize_image_instance (p=0x886a2f0) at glyphs-x.c:422
422 if (IMAGE_INSTANCE_X_MASK (p) &&
(gdb) where
#0 0x81cadc0 in x_finalize_image_instance (p=0x886a2f0) at
glyphs-x.c:422
#1 0x811852c in finalize_image_instance ()
#2 0x8054b77 in sweep_lcrecords_1 ()
#3 0x80562fd in garbage_collect_1 ()
#4 0x80970bc in Feval ()
#5 0x814b05e in readevalloop ()
#6 0x81494fd in Fload_internal ()
#7 0x809827d in Ffuncall ()
#8 0x8064496 in execute_optimized_program ()
#9 0x8064035 in funcall_compiled_function ()
#10 0x809838b in Ffuncall ()
#11 0x809bd64 in call4 ()
#12 0x8096a61 in do_autoload ()
#13 0x80983fc in Ffuncall ()
#14 0x8064496 in execute_optimized_program ()
#15 0x8064035 in funcall_compiled_function ()
#16 0x809838b in Ffuncall ()
#17 0x8064496 in execute_optimized_program ()
#18 0x8064035 in funcall_compiled_function ()
#19 0x809838b in Ffuncall ()
#20 0x8069ee8 in Fcall_interactively ()
#21 0x8096716 in Fcommand_execute ()
#22 0x80dd22e in execute_command_event ()
#23 0x80de128 in Fdispatch_event ()
#24 0x80746c7 in Fcommand_loop_1 ()
#25 0x8074915 in command_loop_1 ()
#26 0x8094cc7 in condition_case_1 ()
#27 0x80749f0 in command_loop_2 ()
#28 0x809c605 in internal_catch ()
#29 0x8073d19 in initial_command_loop ()
#30 0x809007a in xemacs_21_2_b19_i586_pc_linux (argc=1,
argv=0xbffff714, envp=0xbffff71c, restart=0) at emacs.c:1824
#31 0x80920cd in main (argc=1, argv=0xbffff714, envp=0xbffff71c) at
emacs.c:2249
#32 0x4040b213 in __libc_start_main (main=0x8091fb0 <main>, argc=1,
argv=0xbffff714, init=0x804e9a0 <_init>, fini=0x81fe0f0 <_fini>,
rtld_fini=0x4000ac30 <_dl_fini>, stack_end=0xbffff70c) at
../sysdeps/generic/libc-start.c:90
(gdb)
uname -a: Linux zaphod 2.2.12 #3 Thu Oct 7 15:20:57 CEST 1999 i586 unknown
./configure '--with-toolbars=no' '--with-mule=yes' '--with-offix=yes' '--with-scrollbars=motif' '--with-dialogs=motif' '--prefix=/opt/xemacs'
XEmacs 21.2-b19 "Shinjuku" configured for `i586-pc-linux'.
Where should the build process find the source code? /home/khaberz/sources/xemacs/xemacs-beta/xemacs
What installation prefix should install use? /opt/xemacs
What operating system and machine description files should XEmacs use?
`s/linux.h' and `m/intel386.h'
What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch
Should XEmacs use the GNU version of malloc? yes
(Using Doug Lea's new malloc from the GNU C Library.)
Should XEmacs use the relocating allocator for buffers? yes
What window system should XEmacs use? x11
Where do we find X Windows header files? /usr/X11/include
Where do we find X Windows libraries? /usr/X11/lib
Compiling in support for XAUTH.
Compiling in support for XPM images.
--------------------------------------------------------------------
WARNING: Compiling without PNG image support.
Reason: PNG library version and header file don't match!
WARNING: You should strongly consider installing the PNG libraries.
WARNING: Otherwise certain images and glyphs may not display.
WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux)
--------------------------------------------------------------------
Compiling in support for (builtin) GIF image handling.
Compiling in support for JPEG image handling.
Compiling in support for TIFF image handling.
Compiling in native sound support.
Compiling in support for Berkeley DB.
Compiling in support for GNU DBM.
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Compiling in Mule (multi-lingual) support.
Compiling in XIM (X11R5+ I18N input method) support.
Using raw Xlib to provide XIM support.
Compiling in support for OffiX.
Compiling in EXPERIMENTAL support for Drag'n'Drop ( OffiX ).
Compiling in support for proper WM_COMMAND handling.
Using Lucid menubars.
Using Motif scrollbars.
Using Motif native widgets.
Using Motif dialog boxes.
Compiling in DSO module support.
movemail will use "dot-locking" for locking mail spool files.
Compiling in extra code for debugging.
WARNING: ---------------------------------------------------------
WARNING: Compiling in support for runtime error checking.
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
- 1 participants
- 0 comments