Subject: Re: Pesky Newbie

From: Mark Bergstrom <[email-masked]>
Date: Thu, 24 Jun 1999 12:04:05 -0700 (PDT)

I am taking the sense of this to be that you don't only mean for HP/UX.
If so, I'd flag a few fine point details for the other OSs.

For example, on Solaris2.5.1 and 2.6 in the building of libraries from what
the configure figures out for a pgpk build works but breaks in key
generation on the HAVE64 check giving a Bus error.
  To wit,
>Kris Van Hees <[email-masked]> wrote: 

> traced the problem to the struct MD5Context, which contains a conditional
for HAVE64, which is set
> along with typedefs in include/pgpUsuals.h. I am not certain why, but
using that
> auto-resolving finds a 64bit type as 'unsigned long long', and thus sets
HAVE64. Yet when
> used in code this fails. I think this might be a problem with GCC/Solaris
interaction. A Bus Error
> sounds to me as a possible alignment problem there. 
>
> I manually disabled the HAVE64 check, so that the code will use two 32bit
words, and that
> solved the problem. 

and under the versions of IRIX,  
2.7.2.2 is needed to support -o32 and will not do -n32.

contrariwise,
2.8.1 will only do -n32  (& 64) and should be fine on all the 6.2, 6.3, &
6.4 systems that have NOT either upgraded their compiler or patch (this a
very subtle way your working compiler suddenly breaks because you downloaded
the latest patch set and put them all in without carefully discriminating)
that affects front-end or back-end internal compiler [aka whirl] .so's
beyond the 7.11 (or possibly the earliest 7.2).  After that the compiler is
not part of the IDO package.

However,gcc version 2.8 and upwards does support SGI's new ABIs (n32 and
64). The default compilation mode is n32 (-mabi=n32). To compile 64-bit use:
gcc -mabi=64 ... 

.....er, subject to all the below.

Here is the step-by-step to build gcc-2.8.1 from scratch:
http://reality.sgi.com/ariel/freeware/gcc-2.8.1.html

On  6.5.x,  the default development base contains a different break-up of
the two because the compiler now requires a flexlm license.  Even without
the for-pay compiler, it is necessary to install the assembler and linker
from the Development Foundation CDs to make things work.

The SGI back end (including an assembler and linker supporting the n32 and
64 ABIs) plus all the bits and pieces needed for gcc (headers, libraries,
runtime startup files, etc.) are included for free with any IRIX 6.5
distribution on the 2 CDs titled Development Foundation and Development
Libraries (in other words you don't need to have the SGI IDO in order to use
gcc.) In recent SGI compiler releases, the SGI assembler and linker are in
the subsystem: compiler_dev.sw.base. 

And for the architectures (Origin 200,2000) that support it, these are the
known bugs:
Known Bugs

          Unlike the SGI cc, gcc 2.8.1 does not support the o32 (old 32 bit)
ABI. Unlike the SGI cc, gcc 2.8.1 does not seem to support 128-bit
quantities like long double and long long on MIPS.
 
          Gcc does not correctly pass/return structures which are smaller
than 16 bytes and which are not 8 bytes. The problem is very involved and
difficult to fix. It affects a number of other targets also, but irix6 is
affected the most, because it is a 64 bit target, and 4 byte structures are
common. The exact problem is that structures are being padded at the wrong
end, e.g. a 4 byte structure is loaded into the lower 4 bytes of the
register when it should be loaded into the upper 4 bytes of the register. 

          Gcc is consistent with itself, but not consistent with the SGI C
compiler [and the SGI supplied runtime libraries], so the only failures that
can happen are when there are library functions that take/return such
structures. There are very few such library functions. I can only recall
seeing a few of them: inet_ntoa, inet_aton, inet_lnaof, inet_netof, and semctl. 

          A possible workaround: if you have a program that calls inet_ntoa
and friends or semctl, and your kernel supports 64-bit binaries (i.e. uname
-a prints IRIX64 rather than just IRIX), then you may compile with gcc
-mabi=64 to workaround this problem. 

DECunix/alpha also has certain 64-bit oddities that require adjustment.

NextStep3.3 on Intel and Openstep on Mach may not correctly interpret all
the macros under gcc-2.8.1.

That's all I can think of.
Hope that helps if you are planning an overhaul to standardize to gcc.
I didn't solve all these myself but I certainly have run into about 75% of
them because our developers keep picking 3rd-party or open source products
that don't take advantage of the qualities inherent in the native compilers
(for which we have licenses) and keep picking ones that require
gcc-dependence in some very bizarre ways.

Mark Bergstrom
Secure Network Architect
Citysearch--TicketMasterOnline

At 03:28 PM 6/23/99 -0400, Gregory A Lundberg wrote:
>On Wed, 23 Jun 1999, Koos van den Hout _U nix and we all_ wrote:
>
>> Quoting Bob Luckin who wrote on Wed, Jun 23, 1999 at 02:04:11PM -0500:
>> 
>> > The options supplied in the makefile are for the full version of the
compiler,
>> > which is why it barfs when you only have the default compiler available.
>> 
>> Time for a version of the Makefile(s) for gcc ?
>
>The number of times this has come up in the past few months, I'd say the
>daemon should switch to using gcc by default on HP/UX with notes about how
>to use the for-pay compiler placed in the Makefiles.  either way we're
>goning to have questions, but if we go toward gcc, I think we'll have a
>few less.
>
>> > there.  If/when you do find out what to do, it would also be a good idea to
>> > ask Koos to add it to the FAQ (I assume you checked that before posting).
>> 
>> This information would be very usefull for the faq indeed.
>
>For the past couple of months, HP/UX questions have come up a bit more
>often than usual.
>
>-- 
>
>Gregory A Lundberg              Senior Partner, VRnet Company
>1441 Elmdale Drive              [email-masked]
>Kettering, OH 45409-1615 USA    1-800-809-2195
>
______________________________________________________________________________
UNIX TEAM -- The Internet never sleeps and neither do we