From: Vic Pulver [[email protected]]
Newsgroups: comp.infosystems.www.servers.unix,comp.sys.sgi.admin
Subject: Re: REMOTE_ADDR ENV var giving 255.255.255.255
Date: Tue, 21 Sep 1999 06:14:49 GMT
Organization: Deja.com - Share what you know. Learn what you don't.
Xref: daresbury comp.infosystems.www.servers.unix:70433 comp.sys.sgi.admin:85166


There's an incompatability between gcc 2.8.1 and irix libraries,
particularly those which convert internet addresses. It affects apache,
ssh, and other programs (search sgi 255.255.255.255 on deja.com).

You can either compile with cc, or download an earlier version of gcc.
I don't remember which gcc we are using to compile apache, but it is
the one which supports -o32; the newer ones (which have the problem
with the libraries) support -n32 but not -o32.

For more info, see
http://toolbox.sgi.com/TasteOfDT/public/freeware/1999Aug/Installable/gcc-2.8.1-sgipl2.html :

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.

In article [[email protected]],
  Richard Robinson [[email protected]] wrote:
> We have one machine (an SGI box, IRIX 6.x, I believe) on our network
> that is running Apache 1.3.6.
>
> For some reason, the REMOTE_ADDR variable is always returning
> 255.255.255.255, instead of the real remote address of user/browser
> connecting.
>

> --
> Richard Robinson
> Web Administrator
> Litho Development & Research
> [email protected]
> 503-255-5800 x172
>
>

--
Internet Developer, Los Angeles Times
http://www.latimes.com
http://www.calendarlive.com
[email protected]

From: [email protected] (David Evans)
Newsgroups: comp.sys.sgi.admin
Subject: Re: problem with gcc or apache? (DNS logging oddities)
Date: 22 Apr 2000 01:11:34 GMT
Organization: University of Waterloo
Lines: 22

In article [[email protected]],
J Hart  ["You can't email here"@saturn.med.nyu.edu] wrote:
>
>and if I get a connection from anywhere other than the local host, the
>lines I get all start with
>255.255.255.255 -- [ ...
>

  This is the classic gcc "structure-in-a-register" bug.  It bit me
last fall and I asked here, generating a flurry of responses.  The
specific symptom is buggering of the input to inet_ntoa().

  If you want the logging to work you could either write your own
version of inet_ntoa(), build it with gcc, and ensure that it's
sucked up at link time.  Or you could just use your binary made on the
machine with MIPSPro.

-- 
David Evans          (NeXTMail/MIME OK)             [email protected]
PhD Student, Computer/Synth Junkie         http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo         "Default is the value selected by the composer

From: Tom Mitchell [[email protected]]
Newsgroups: comp.sys.sgi.admin
Subject: Re: problem with gcc or apache? (DNS logging oddities)
Date: Mon, 24 Apr 2000 10:44:38 -0700
Organization: Silicon Graphics Computer Systems
Lines: 33


On 22 Apr 2000, David Evans wrote:
> >
> >and if I get a connection from anywhere other than the local host, the
> >lines I get all start with
> >255.255.255.255 -- [ ...
> >
> 
>   This is the classic gcc "structure-in-a-register" bug.  It bit me
> last fall and I asked here, generating a flurry of responses.  The
> specific symptom is buggering of the input to inet_ntoa().

Could be.  Look also at varargs (variable argument list).

Simply adding an
        #include <varargs.h>
can clean up problems with some programs.

Too many subroutines were written with 'subtle' expectations
in the procedure calling routines. Even the classic printf()
calls can get in trouble. As optimizations increase there is
more trust that the author used the language correctly (thus
reducing optimization can sometimes help (hide the problem)).

See also stdarg(5)

>   If you want the logging to work you could either write your own
> version of inet_ntoa(), build it with gcc, and ensure that it's
> sucked up at link time.  Or you could just use your binary made on the
> machine with MIPSPro.
> 
> 

From: Lauri Jesmin 
Newsgroups: comp.sys.sgi.admin
Subject: Re: problem with gcc or apache? (DNS logging oddities)
Date: 6 May 2000 14:23:56 GMT
Lines: 52

David Evans [[email protected]] wrote:
>   This is the classic gcc "structure-in-a-register" bug.  It bit me
> last fall and I asked here, generating a flurry of responses.  The
> specific symptom is buggering of the input to inet_ntoa().

>   If you want the logging to work you could either write your own
> version of inet_ntoa(), build it with gcc, and ensure that it's
> sucked up at link time.  Or you could just use your binary made on the
> machine with MIPSPro.
I wrote inet_ntoa and inet_aton functions by myself and linked them
into programs where needed. It works form me.. postfix
(mail server) now works :) 
This is what is looks like: 

#include <stdio.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/socket.h>
#include <varargs.h>
char *inet_ntoa(struct in_addr kaka) {
        char *vastus;
        struct hostent *he;
        unsigned int u;

        he=gethostbyaddr(&kaka.s_addr,sizeof(struct in_addr),AF_INET);
        if (!he) return NULL;
        return strdup(he->h_name);
}

int inet_aton(const char *nimi , struct in_addr *kaka) {
                struct hostent *he;
                struct in_addr *kamm;

                he=gethostbyname(nimi);
                if (!he) return 0;
                kamm=he->h_addr;
                kaka->s_addr=kamm->s_addr;
                return 1;
}

> -- 
> David Evans          (NeXTMail/MIME OK)             [email protected]
> PhD Student, Computer/Synth Junkie         http://bbcr.uwaterloo.ca/~dfevans/
> University of Waterloo         "Default is the value selected by the composer
> Ontario, Canada           overridden by your command." - Roland TR-707 Manual

-- 
Lauri Jesmin ([email protected])
Et oma ridu sisseimbuva kahtlase elemendi eest hoida,tuleb iga n�dal

Date: Mon, 07 Aug 2000 11:58:45 +0200
From: Alexis Cousein [[email protected]]
Newsgroups: comp.sys.sgi.admin
Subject: Re: gcc 2.95.2 on Irix 6.5.8

[email protected] wrote:
>
> Even if you are able to compile SSH with gcc 2.95.2, you will soon hit
> another snag.
>
> The gcc libraries that convert internet addresses are broken. This
> effects Apache and SSH.

That is incorrect. The problem is that these installations rely on the
standard libc() routines, and there's a bug in the N32 implementation of
the MIPS ABI by gcc -- so the bug is that there aren't "gcc libraries"
(as libraries compiled with gcc are interoperable with gcc binaries in
this respect -- they both implement the same ABI conventions, albeit not
the official MIPS N32 ABI conventions).

There are several workarounds -- do an archive search on i n e t _ n t o
a to find some pointers.

[BTW, the reason that gcc 2.7.2 doesn't encounter this problem is simply
that it uses an different, older O32 ABI]

--
[standard disclaimer: these are my personal views, not SGI's]
Alexis Cousein                  [email protected]
Systems Engineer                SGI Belgium/Luxemburg

From: http://w3.physics.uiuc.edu/~menscher/vfemmes.html

This document outlines steps to compile a recent version of Sendmail for IRIX 6.2 without resorting to SGI's native cc compiler.

• if you don't already have it, download the latest version of gcc from freeware.sgi.com
• download Sendmail from www.sendmail.org
• in devtools/OS/IRIX.6.x modify the compiler to be /usr/freeware/bin/gcc
• download the latest version of inn (available from ftp.tin.org:/pub/news/servers/inn-snapshot)
• copy the files inet_aton.c and inet_ntoa.c from the lib directory of inn into the libmilter and sendmail directories of sendmail
• modify those files to remove the reference to #include "config.h"
• modify the Makefile.m4 in those directories to add these two new files to the bldSOURCES list
• go to the main sendmail directory and type ./Build
• while it is compiling, go to www.qmail.org and start a download of qmail (this is to scare sendmail into working)
• assuming you've made it this far, you can create your sendmail.cf file and do a ./Build install

Why was all of this necessary?