Thread: 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.
> > 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. > I know other people are using Irix. initdb problems are very hard to debug. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> 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.
> 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.
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
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
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: > > 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. > > 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 > > -- > Thomas Lockhart lockhart@alumni.caltech.edu > South Pasadena, California >
On Tue, 4 May 1999, Thomas Lockhart wrote: > > 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. > 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. Ah, I see now. > Another option is to explicitly disable using readline; umh, before I going down that path, what effect would it have on postgres? Thanks heap, rOnn c.
> > Another option is to explicitly disable using readline;
> umh, before I going down that path, what effect would it have on postgres?
afaik, it would keep you from being able to use your arrow keys (and
other keys) to manipulate text typed into psql.
- Tom
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart writes: > > > Another option is to explicitly disable using readline; > > umh, before I going down that path, what effect would it have on postgres? > > afaik, it would keep you from being able to use your arrow keys (and > other keys) to manipulate text typed into psql. > 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.