Core dump with initdb on Irix 6.2

Hi there,

I've been having this problem for a few weeks now. Postgres 6.4.2
installed beautifully on my freeBSD 3.0 at home but on Irix6.4 at work, it
gives me many many compiler warnings.

Although, it claims that it is compiled and installed successfully, when
I run initdb I get a core dumped on creating the template database.

I've been through the previous postings, does anybody has any solution to
this??? I really like postgres but if it doesn't work I'll have to use
something else then. Any suggestions would be greatly appreciated.

rOnn c.

I know other people are using Irix. initdb problems are very hard to
debug.

After switching to gcc 2.8.1 (thanks to Remi), I've managed to get initdb
and postmaster running now - woo who!!

However, my excitement was short live. After examining make log, I find
that psql doesn't compile. Hence createdb will stall.

Here's the message
ld32: FATAL 12: Expecting n32 objects:
/usr/local/lib/libreadline.a(readline.o) is o32.

How shouild I fix this? I'm now using gcc 2.8.1 My environment variable
SGI_ABI is set to -n32.

Any idea anybody?

rOnn c.

It looks like libreadline (which you installed earlier) was built
using o32, whatever that is, and that is different from n32. Try
rebuilding libreadline or build all of postgres with using o32.

Another option is to explicitly disable using readline; look in
config.h or figure out how to disable it using configure.

Good luck.

- Tom

You must take care of a bug with gcc-2.8.1 on irix: there is a wrong
padding of 4 bytes structures when calling MipsPro C compiled
functions (such as the whole irix libc) by gcc-compiled functions (see
http://reality.sgi.com/ariel/freeware/gcc-2.8.1-notes.html
paragraph "Known bugs"). You will run into this bug when the
postgres backend call semctl(), (in src/backend/storage/ipc/).

As a quick and dirty workaround (please tell me if you find a better
solution), I modified my /usr/include/sys/sem.h and
/usr/include/arpa/inet.h :

/usr/include/sys/sem.h :

#ifndef _KERNEL
#if defined(sgi) && defined(__GNUC__) && defined(_ABIN32)
#define semctl gnu_semctl
#else
extern int semctl (int, int, int, ...);
#endif
extern int semget (key_t, int, int);
extern int semop (int, struct sembuf *, size_t);
#endif

/usr/include/arpa/inet.h :

#if defined(sgi) && defined(__GNUC__) && defined(_ABIN32)
#define inet_lnaof gnu_inet_lnaof
#define inet_netof gnu_inet_netof
#define inet_ntoa gnu_inet_ntoa
#else
extern in_addr_t inet_lnaof(struct in_addr);
extern in_addr_t inet_netof(struct in_addr);
extern char * inet_ntoa(struct in_addr);
#endif

and I (gcc-) compiled a library with :

workaround.h :

#if !defined(sgi) || !defined(__GNUC__) || !defined(_ABIN32)
ERROR !defined(sgi) || !defined(GNUC) || !defined(_ABIN32)
#endif

char *gnu_inet_ntoa(struct in_addr in);
unsigned long int gnu_inet_lnaof(struct in_addr in);
unsigned long int gnu_inet_netof(struct in_addr in);
int gnu_semctl(int semid, int semnun, int cmd, union semun arg);

workaround.c :

#if !defined(sgi) || !defined(__GNUC__) || !defined(_ABIN32)
ERROR !defined(sgi) || !defined(GNUC) || !defined(_ABIN32)
#endif

#include <sys/types.h>

struct in_addr {

unsigned long int s_addr;
};

char *gnu_inet_ntoa(struct in_addr in) {

return inet_ntoa( (int64_t)in.s_addr << 32 );
}

unsigned long int gnu_inet_lnaof(struct in_addr in) {

return inet_lnaof( (int64_t)in.s_addr << 32 );

}

unsigned long int gnu_inet_lnaof(struct in_addr in) {

return inet_lnaof( (int64_t)in.s_addr << 32 );

}

unsigned long int gnu_inet_netof(struct in_addr in) {

return inet_netof( (int64_t)in.s_addr << 32 );

}

union semun {
int val; /* used for SETVAL only */
struct semid_ds *buf; /* for IPC_STAT and IPC_SET */
ushort *array; /* used for GETALL and SETALL */
};

int gnu_semctl(int semid, int semnun, int cmd, union semun arg) {

return semctl(semid, semnun, cmd, (int64_t)arg.val << 32 );

}

Then, when compiling with gcc-2.8.1 in n32 binary with irix,
semctl() is changed in gnu_semctl(), and, of course, the final
link must include the workaround library.

PostgreSQL doesn't use inet_xtoy (does it ?). These functions
(semctl() and inet_xtoy) seem to be the only ones in the irix
libc that make problems.

I hope this will help,

Rémi.

Thomas Lockhart writes:
>
>

umh, before I going down that path, what effect would it have on postgres?

Thanks heap,

rOnn c.

afaik, it would keep you from being able to use your arrow keys (and
other keys) to manipulate text typed into psql.

- Tom

>
>

which is not a problem if you run psql from a shell buffer in emacs...

Rémi.

Hi again,

I've been away from the problem for a while, but after following Remi
instructions, Postgres 6.4.2 is now working on the old SGI box. Huray!
now I can get on with some productive work.

Thanks very much, I don't think I could get it going without your tips!

Regards,
rOnn c.