building krb5-1.4 on hpux and solaris with native compilers

Arlene Berry aberry0364 at
Mon Feb 14 19:58:29 EST 2005

>From: Ken Raeburn <raeburn at MIT.EDU>
>To: "Arlene Berry" <aberry0364 at>
>CC: krbdev at
>Subject: Re: building krb5-1.4 on hpux and solaris with native compilers
>Date: Mon, 14 Feb 2005 15:59:52 -0500
>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).

I want both actually.

>>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/  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/  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 
>>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.

Yes.  I don't have a Solaris 8 box set up at the moment but the man page on 
Sun's web site indicates it supports the same options as 9.  Gcc isn't our 
favorite because we've found that you get unresolved references at run-time 
unless you have the gcc libraries available or force it to statically link 
one of them.

>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?

The linker comes with the OS.  Compilers are purchased separately which is 
why we're using an old one.  It does include a C++ compiler.  I've been 
digging deeper into the manuals and found this in 
the Linkers and Libraries Guide for Solaris 9.  It covers all of the ways 
initialization and termination routines can be declared.  One method is via 
pragmas which is supported by our compiler as well as by newer compilers.

>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 
>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.)

Here's HP's info. on initializers:  It's not 
100% correct as it says 11.25 and up supports +fini and +init for both 32 
and 64-bit modes.  However, my patched 11.11 system says it supports +fini 
and +init for both 32 and 64-bit modes and, after I patched it today, so 
does my 11.0 system.  The +I option is available on 10.20, available for 
both bit modes on 11.0, and available for 32-bit mode only on 11.11.

You wouldn't use both the pragmas and the linker options as they are two 
different methods for accomplishing the same thing.

>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.

Unfortunately, our unix systems are all on a development network which does 
not have external access but I would be happy to help in other ways.

Don’t just search. Find. Check out the new MSN Search!

More information about the krbdev mailing list