building krb5-1.4 on hpux and solaris with native compilers

[Ken Raeburn]

Ah, yes, HP-UX and Solaris 7, two more systems not in our current test 
environment, and apparently not run by anyone who picked up our beta 
releases....  ☹

On Feb 14, 2005, at 12:56, Arlene Berry wrote:
> I have tried building krb5-1.4 on several versions of both hpux and 
> solaris.  I ran into a number of issues some of which I was able to 
> circumvent and some I was not.  All I really wanted to do was a simple 
> "configure --enable-static" and make using native tools.  None of the 
> versions of solaris and hpux I tried worked out of the box.  Here are 
> all of the issues I ran into:

Note that we're building shared libraries by default now.  If you don't 
want shared libraries, you need --disable-shared as well, and that 
should make some of the problems go away (though it doesn't help us fix 
shared library builds for the next release).

> 1.  On solaris 9 and older versions, the configure worked but the make 
> failed quickly because it tried to run autoconf which is not 
> installed.  I tracked down the cause and it was a "#" character in the 
> dependency rule for configure.  This was due to "@MAINT@" in 
> config/post.in.  MAINT was set to "#" because maintainer mode was 
> disabled.  I tried --enable-maintainer-mode and got past this error 
> but then make wanted to run autoheader.  At this point I reverted to 
> no maintainer mode and removed the "@MAINT@" from config/post.in.  I'm 
> not sure how this should be fixed permanently.

That seems weird.  If maintainer mode is enabled (not the default), 
then the "#" should be commenting out any dependencies which would 
cause autoconf and autoheader to get run (unless maybe the target files 
have been deleted).

> 2.  Solaris prior to version 8 does not support the linker options "-z 
> initarray" and "-z finiarray" but these options are set for all 
> versions of solaris in config/shlib.conf.  I tried removing them and 
> then ran into issue #4.

So this is Solaris 7 and earlier?  I'm okay with saying "use gcc" for 
older platforms, at least as a last resort.

Basically, we're trying to figure out how to get initialization and 
finalization functions run for a library.  (Finalizations like "delete 
this mutex", "free up this heap storage", etc., should be run when 
dlclose is called on a library loaded at run time.  Initialization is 
generally delayed on UNIX until the thing to be initialized is first 
used, and then the initialization is protected with a call to 
pthread_once if the pthread code is available, or a simple static 
variable in the single-threaded case.)  With gcc, there are function 
attributes we can use to tell it to invoke whatever support it would 
use for C++ static objects with constructors and destructors.  Without 
gcc, we need another way to invoke that functionality.  For current 
Solaris tools, the linker option works; for earlier versions, I'm not 
sure what to use, and I don't think I have such machines available to 
investigate it.

Could you check the compiler and linker man pages for Solaris 7 and see 
if there are other options we should use?  Do you have a C++ compiler 
installed?  What does it do?

However, as Sam pointed out to me earlier today when we discussed this, 
if you're building static libraries, and delayed initialization is 
used, we shouldn't care about the linker support.  The pthread_once 
magic will take care of initialization, and finalization would only 
happen while the process is exiting (and freeing up all the resources 
we currently use) anyways.  That's not how our code is set up to work 
at the moment, but I'll try to fix that.

> 3.  On solaris I'm getting multiple warnings of the form: 
> /opt/SUNWspro/bin/../SC4.0/bin/fbe: "/tmp/yabeAAAIdaymB", line 2137: 
> warning: label in delay slot (follows CTI).  Fbe is the assembler 
> component of the compiler.  I have no idea what this means, what's 
> causing this, or where to start looking.  I am using an older compiler 
> but I have never seen this warning before.  Any help would be 
> appreciated.

This is a bit of a digression, but...

In the sparc architecture, the "branch" or "call" instructions have 
what's called a "delay slot".  It means that when the part of the 
processor that deals with jumping to a new address gets around to 
processing them and coming up with the new address, the instruction 
following the branch instruction has already been read in by the 
instruction-fetching part of the processor, and it'll get executed 
before the instructions at the new address do.  This one-instruction 
slot after the branch instruction is the delay slot.  I think the basic 
idea was to permit better pipelining of instructions through different 
parts of the CPU, without the branch causing everything to stop and 
have to get started up again at the new location in memory.  (It's a 
bit more complicated, actually, with conditional branches and annulled 
instructions.)  So, normally the instruction in the delay slot is 
either an instruction that would've come right before the branch on a 
"normal" machine, or an instruction "borrowed" from the place the 
instruction branches to, so that the normal sequence of instructions 
continues uninterrupted.

A label is usually only put on an instruction if it's going to be an 
instruction that gets jumped to by some other branch or call 
instruction.  That's an odd thing to find in the delay slot, hence the 
assembler issues a warning.  The code may in fact be correct, but if 
so, the Sun compiler should have some way of telling the Sun assembler 
that it was intentional; the assembler generally shouldn't issue 
warnings for plain C code.  (Mixed C and assembly, maybe, but not plain 
C.)

So, in short, I'd call it a compiler bug.  How serious a bug it is 
depends on whether the generated code is actually correct -- i.e., is 
it a warning you can ignore, or might it cause the program to break?  
That, I can't tell....

Sounds like another argument for using gcc. :-)

> 4.  On multiple versions of hpux and older versions of solaris I got:  
> "k5-platform.h", line 261: error 4062: "Don't know how to do load-time 
> initializers for this configuration."  This looked like it was related 
> to the dynamic library initialization and that 
> --disable-delayed-initialization might have some effect.  It didn't.  
> I have tried various things and none of them seemed to do anything.  
> Does anyone how to get around this?

See under #2 above.

Delayed initialization (that's not really intended to be a user option, 
btw, but I needed it for testing different cases) should be enabled by 
default on UNIX, so DELAY_INITIALIZER should be defined in 
include/krb5/autoconf.h, so the test at line 143 should be true and the 
error should never be reachable.  Disabling the delayed initialization 
-- that is, requiring initialization to happen at library load time -- 
will cause an error to be emitted if gcc constructor attributes can't 
be used and there isn't a known linker option (in shlib.conf) to do the 
job.

However, even with delayed initialization, if you're building shared 
libraries, the finalization option is still needed or you'll get a very 
similar error message at line 299.

Could you check the docs on HP-UX too, and see if there are compiler or 
linker options we should be using for this?  We don't have a good HP-UX 
test system at the moment.

I found a document on shared libraries for some version of HP-UX, 
indicating that for "HP-UX 10 style initializers" you can give the 
linker the name of a function to be run both at load time and at unload 
time, with an argument telling you which invocation it is.  If that 
works, we could build on it, though it would be pretty awkward.  For 
64-bit mode, it appears that another form is supported, more like what 
I've been expecting, with separate linker options and pragmas for 
initializers and finalizers.  But I don't know how to tell from the 
shell (where we decide which options to use) whether we're in 64-bit 
mode or stuck with the HP-UX 10 style initializers.  And it's not clear 
if both the pragma and the linker option must be used, or if either 
will suffice; the pragma, being a preprocessing-style directive, would 
be tough to produce as output from the initializer-declaring macro 
we're currently using.

And glancing at some old notes from the gcc mailing list, it looks like 
the HP linker used to have some bugs where the init/fini functions 
might be executed in the wrong order, so linker patches may be needed.  
(Basically, same as to ensure that C++ libraries work properly.)

Ken

P.S.  Worst case, with a guest account and disk space for a few days, I 
could probably get this working.  And preferably access to gcc as well 
as the native compiler.