configure gets PICFLAG wrong on UnixWare

[Michael Davidson]

I just tried building HEAD on a UnixWare system and got a flood
of very strange warning messages from the compiler as it tried
to build the PIC objects for the libsmbclient shared library ...

UW: cc: warning -o has renamed the output of -P, perhaps unintentionally

On closer examination I discovered that configure had decided that
the PICFLAG for the compiler should be -fPIC.

Unfortunately, -fPIC is a legal (OK, *almost* legal) option to the
UnixWare C compiler, but it doesn't mean "generate PIC code" ...

... it means something like:

-f	linker option - which would be found to be invalid if we ever
	invoked the linker, which we don't since the next option looks
	like ...

P	which says to run the preprocessor and (by default) leave the
	resulting output in a .i file, and ...

IC	which says to include the directory C in the search path for
	include files ...

Ughhh ...

One fix for this would be to change the order of the checks in
configure.in so that we try -KPIC (which is the correct option
for this compiler) *before* -fPIC rather than after it as things
currently are. Another possibility would be to chcek that the
result of compiling with -fPIC actually produced a .o object file.

I also noticed that the shared objects are currently generated by
invoking the linker, ld, directly. I realise that this is something
which is very platform dependent, but it is usually better, on UnixWare
at least, to use the cc command rather than ld since this ensures that
runtime support libraries (such as libcrt.a which supports 64 bit
long long division) are automatically linked into the shared object.

If you invoke ld directly you still get a useable shared object but
it will typically have some text relocations as a result of unresolved
references to runtime support routines which will have the effect of
making the object somewhat less shareable because some of it's text
pages will have to be modified at load time.