[ST-devel] autoconf and libst

[Wesley W. T. <we...@te...>]

Ok, I've got most of the autoconf stuff going now. However, I had to make
some source level changes to make it work and there are a few things still
remaining:

From what I can see, md.h sets several macros based on the machine. This is
the main thing that needs to be setup to be auto-detected by autoconf.

MD_STACK_GROWS_UP/DOWN:

	I can't see how to detect this during configure without breaking
cross-compilation. To work with cross-compiling you'd have to somehow fail
to compile if it is STACK_GROWS_DOWN. It's easy enough to detect this at
runtime anyways, and it's only in one file: stk.c and called at thread
creation time. Hence I assume the cost to speed is not important?

MD_USE_SYSV/BSD_ANON_MMAP:

	I have a couple ideas how to deal with this.
	Idea 1:
#ifdef MAP_ANON
do BSD stuff
#els
do SYSV stuff
#endif

	Idea 2:
always open /dev/zero
#ifdef MAP_ANON
flags |= MAP_ANON;
#endif
mmap

	I don't know enough about mmap to know whether these would work
however. -- PS. What's wrong with malloc?

MD_ACCEPT_NB_INHERITED:

	Why not just assume it's not inherited and always reset the thing
nonblocking? Is it really such a performance hit?

MD_ALWAYS_UNSERIALIZED_ACCEPT:

	I don't know enough about this to write a test. Could someone give
me a hand?

MD_HAVE_SOCKLEN_T:

	No problem for autoconf

MD_SETJMP/MD_LONGJMP:
	
	I am presently running this order of tests:
	if __ia64__ defined, use _ia64_cxt_* and include the assembly file.
	if setjmp available, use it
	if _setjmp available, use it
	fail with an error

	PS what's wrong with setjmp/longjmp for ia64?

MD_GET_UTIME:

	Test for these functions:
	read_real_time time_base_to_time gettimeofday
	syssgi clock_gettime gethrtime ftime

	Use them in this order:
	gettimeofday
	read_real_time & time_base_to_time
	syssgi & clock_gettime
	gethrtime
	ftime
	fail with an error

MD_INIT_CONTEXT:

	I have no idea how to check for this one. If I were willing to give
up cross-compilation I would simply write a test which tried each and use
the one which doesn't crash. :-) However, I would rather not... The other
option would be to examine the target machine's name and have a big lookup
table for each machine. I am guessing this define is why the current 'make
target' exists.

So, to summarize: I have it mostly autoconf/automake/libtool/rpm/deb'd up.
As soon as I get some idea as to how to tackle MD_INIT_CONTEXT and the
SERIALIZED_ACCEPT, I'll put together a tar.gz to be perused by you folks.

If I don't hear back from anybody, I'm going to assume that the order I
check for things will work, always use serialized accept, and use a lookup
based approach to MD_INIT_CONTEXT.

Hope to hear back from you guys!

-- 
Wesley W. Terpstra <we...@te...>