Обсуждение: Problems compiling PostgreSQL 6.4 on Digital Unix 4.0d
I am having some trouble compiling version 6.4 on Digital Unix 4.0d. The
first problem I ran into was a function prototyping error in snprintf.c.
Here is the SCCS diff of the fix that I had to do to make it compile:
------- snprintf.c -------
123a124,126
> #ifdef HAVE_LONG_INT_64
> static void fmtnum __P((long_long value, int base, int dosign, int ljust, int len, int zpad));
> #else
124a128
> #endif
However, now the compile fails with all of this:
gcc -I../../../include -I../../../backend -DNOFIXADE -Wall
-Wmissing-prototypes -I../.. -c buf_init.c -o buf_init.o
../../../include/storage/s_lock.h: In function `tas':
In file included from buf_init.c:29:
../../../include/storage/s_lock.h:102: aggregate value used where an
integer was expected
buf_init.c: In function `InitBufferPool':
buf_init.c:234: incompatible types in assignment
gmake[3]: *** [buf_init.o] Error 1
gcc -I../../../include -I../../../backend -DNOFIXADE -Wall
-Wmissing-prototypes -I../.. -c ipc.c -o ipc.o
In file included from ../../../include/libpq/libpq-be.h:21,
from ../../../include/libpq/libpq.h:20,
from ipc.c:41:
../../../include/libpq/hba.h:22: warning: `MAP_FILE' redefined
/usr/include/sys/mman.h:73: warning: this is the location of the
previous definition
../../../include/storage/s_lock.h: In function `tas':
In file included from ipc.c:36:
../../../include/storage/s_lock.h:102: aggregate value used where an
integer was expected
ipc.c: In function `IpcSemaphoreCreate':
ipc.c:367: warning: cast to pointer from integer of different size
ipc.c: In function `IpcMemoryCreate':
ipc.c:569: warning: cast to pointer from integer of different size
ipc.c: In function `CreateAndInitSLockMemory':
ipc.c:699: incompatible types in assignment
ipc.c:702: incompatible types in assignment
ipc.c:703: incompatible types in assignment
ipc.c:704: incompatible types in assignment
ipc.c: In function `AttachSLockMemory':
ipc.c:725: incompatible types in assignment
gmake[3]: *** [ipc.o] Error 1
And then:
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/buffer'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/src
/backend/storage/buffer'
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/file'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/src
/backend/storage/file'
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/ipc'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/src
/backend/storage/ipc'
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/large_object'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/src
/backend/storage/large_object'
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/lmgr'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/src
/backend/storage/lmgr'
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/page'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake[3]: Leaving directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/src
/backend/storage/page'
gmake[3]: Entering directory
`/usr/src/id/dunix/usr/local/bin/postgresql-v6.4/sr
c/backend/storage/smgr'
gmake[3]: *** No rule to make target `buffer/SUBSYS.o'. Stop.
gmake: *** [all] Error 2
Can someone suggest fixes for these errors?
Thanks,
Carl
Carl G. Riches
Software Engineer
Department of Mathematics
Box 354350 voice: 206-543-5082 or 206-616-3636
University of Washington fax: 206-543-0397
Seattle, WA 98195-4350 internet: riches@ms.washington.edu
> > > I am having some trouble compiling version 6.4 on Digital Unix 4.0d. The > first problem I ran into was a function prototyping error in snprintf.c. > Here is the SCCS diff of the fix that I had to do to make it compile: > > ------- snprintf.c ------- > 123a124,126 > > #ifdef HAVE_LONG_INT_64 > > static void fmtnum __P((long_long value, int base, int dosign, int ljust, int len, int zpad)); > > #else > 124a128 > > #endif > Fix applied: --------------------------------------------------------------------------- *** ./snprintf.c.orig Sat Dec 12 16:28:15 1998 --- ./snprintf.c Sat Dec 12 16:30:00 1998 *************** *** 121,127 **** --- 121,133 ---- */ static void fmtstr __P((char *value, int ljust, int len, int zpad, int maxwidth)); + + #ifndef HAVE_LONG_INT_64 static void fmtnum __P((long value, int base, int dosign, int ljust, int len, int zpad)); + #else + static void fmtnum __P((long_long value, int base, int dosign, int ljust, int len, int zpad)); + #endif + static void dostr __P((char *, int)); static char *output; static void dopr_outch __P((int c)); -- 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
Hi All, As one who is fairly new (within the last two months) to Postgre, I've looked through the Archives for this list a bit and have seen this issue addressed a number of times, but no strong solutions posted. Has anybody devised a good/secure way of allowing users to control their own password on a Postgre system? I'm hoping that either somebody already has a solution to this or that this will possibly spark some discussion on the topic. Thanks, Adam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Adam Maddock http://Adam.Maddock.com Detroit, MI adam@maddock.com "BE IMITATORS of God, therefore, as dearly loved children..." (Ephesians 5:1) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I don't know about secure but what I've done is linked the pg_passwd file to /etc/passwd and then people remote ODBC user can change their database password via the passwd command (or yppasswd). I've got a RH 5.0 system running without shadowed password but with NIS. I'm curious what people think of this from a security standpoint. Adam Maddock wrote: > Hi All, > > As one who is fairly new (within the last two months) to Postgre, I've > looked through the Archives for this list a bit and have seen this issue > addressed a number of times, but no strong solutions posted. Has anybody > devised a good/secure way of allowing users to control their own password > on a Postgre system? > > I'm hoping that either somebody already has a solution to this or that > this will possibly spark some discussion on the topic. > > Thanks, > Adam > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Adam Maddock http://Adam.Maddock.com > Detroit, MI adam@maddock.com > "BE IMITATORS of God, therefore, as dearly loved children..." > (Ephesians 5:1) > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Charles Curley, Staff Engineer Computer Integrated Manufacturing Lockheed Martin Ocala Operations
Hmm... that doesn't work on my system because my system's logon/passwd commands use a different encryption altorhythm than Postgres. I wonder if there is a way to change one or the other's scheme. Did you have to hack anything or did it work "out-of-the-box"? My Linux kernel is 2.0.34 and my distribution is Slackware 3.5. On Thu, 17 Dec 1998, Charles Curley wrote: > I don't know about secure but what I've done is linked the pg_passwd file to > /etc/passwd and then people remote ODBC user can change their database > password via the passwd command (or yppasswd). I've got a RH 5.0 system > running without shadowed password but with NIS. I'm curious what people think > of this from a security standpoint. > > Adam Maddock wrote: > > > Hi All, > > > > As one who is fairly new (within the last two months) to Postgre, I've > > looked through the Archives for this list a bit and have seen this issue > > addressed a number of times, but no strong solutions posted. Has anybody > > devised a good/secure way of allowing users to control their own password > > on a Postgre system? > > > > I'm hoping that either somebody already has a solution to this or that > > this will possibly spark some discussion on the topic. > > > > Thanks, > > Adam > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Adam Maddock http://Adam.Maddock.com > > Detroit, MI adam@maddock.com > > "BE IMITATORS of God, therefore, as dearly loved children..." > > (Ephesians 5:1) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- > Charles Curley, Staff Engineer > Computer Integrated Manufacturing > Lockheed Martin Ocala Operations > >
I am still having problems compiling PostgreSQL 6.4 on Digital Unix 4.0d
(DEC Alpha platform). The problems now are with the macro:
S_INIT_LOCK( )
I can't figure out how this macro is supposed to work and what data type
it is asking for. Here are the error messages and code snippets of
interest. Can someone help me out?
Thanks,
Carl
From:
src/include/storage/s_lock.h:
#if defined(__alpha)
/*
* OSF/1 (Alpha AXP)
*
* Note that slock_t on the Alpha AXP is msemaphore instead of char
* (see storage/ipc.h).
*/
#define TAS(lock) (msem_lock((lock), MSEM_IF_NOWAIT) < 0)
#define S_UNLOCK(lock) msem_unlock((lock), 0)
#define S_INIT_LOCK(lock) msem_init((lock), MSEM_UNLOCKED)
#define S_LOCK_FREE(lock) (!(lock)->msem_state)
#endif /* __alpha */
From:
src/backend/storage/buffer/buf_init.c
#ifdef HAS_TEST_AND_SET
S_INIT_LOCK(&(buf->io_in_progress_lock));
#endif
The resulting error message:
gcc -I../../../include -I../../../backend -DNOFIXADE -Wall
-Wmissing-prototypes -I../.. -c buf_init.c -o buf_init.o
../../../include/storage/s_lock.h: In function `tas':
In file included from buf_init.c:29:
../../../include/storage/s_lock.h:102: aggregate value used where an
integer was expected
buf_init.c: In function `InitBufferPool':
buf_init.c:234: incompatible types in assignment
gmake[3]: *** [buf_init.o] Error 1
From:
src/backend/storage/ipc/ipc.c
void
CreateAndInitSLockMemory(IPCKey key)
{
int id;
SLock *slckP;
SLockMemoryId = IpcMemoryCreate(key,SLockMemorySize,0700);
AttachSLockMemory(key);
*FreeSLockPP = NULL;
*UnusedSLockIP = (int) FIRSTFREELOCKID;
for (id = 0; id < (int) FIRSTFREELOCKID; id++)
{
slckP = &(SLockArray[id]);
S_INIT_LOCK(&(slckP->locklock));
slckP->flag = NOLOCK;
slckP->nshlocks = 0;
S_INIT_LOCK(&(slckP->shlock));
S_INIT_LOCK(&(slckP->exlock));
S_INIT_LOCK(&(slckP->comlock));
slckP->next = NULL;
}
return;
}
void
AttachSLockMemory(IPCKey key)
{
struct ipcdummy *slockM;
if (SLockMemoryId == -1)
SLockMemoryId = IpcMemoryIdGet(key, SLockMemorySize);
if (SLockMemoryId == -1)
elog(FATAL, "SLockMemory not in shared memory");
slockM = (struct ipcdummy *) IpcMemoryAttach(SLockMemoryId);
if (slockM == IpcMemAttachFailed)
elog(FATAL, "AttachSLockMemory: could not attach segment");
FreeSLockPP = (SLock **) &(slockM->free);
UnusedSLockIP = (int *) &(slockM->unused);
SLockMemoryLock = (slock_t *) &(slockM->memlock);
S_INIT_LOCK(SLockMemoryLock);
SLockArray = (SLock *) &(slockM->slocks[0]);
return;
}
The resulting error message:
gcc -I../../../include -I../../../backend -DNOFIXADE -Wall
-Wmissing-prototypes -I../.. -c ipc.c -o ipc.o
In file included from ../../../include/libpq/libpq-be.h:21,
from ../../../include/libpq/libpq.h:20,
from ipc.c:41:
../../../include/libpq/hba.h:22: warning: `MAP_FILE' redefined
/usr/include/sys/mman.h:73: warning: this is the location of the previous
definition
../../../include/storage/s_lock.h: In function `tas':
In file included from ipc.c:36:
../../../include/storage/s_lock.h:102: aggregate value used where an
integer was expected
ipc.c: In function `IpcSemaphoreCreate':
ipc.c:367: warning: cast to pointer from integer of different size
ipc.c: In function `IpcMemoryCreate':
ipc.c:569: warning: cast to pointer from integer of different size
ipc.c: In function `CreateAndInitSLockMemory':
ipc.c:699: incompatible types in assignment
ipc.c:702: incompatible types in assignment
ipc.c:703: incompatible types in assignment
ipc.c:704: incompatible types in assignment
ipc.c: In function `AttachSLockMemory':
ipc.c:725: incompatible types in assignment
gmake[3]: *** [ipc.o] Error 1
Again, thanks for any help you can provide.
Carl
Carl G. Riches
Software Engineer
Department of Mathematics
Box 354350 voice: 206-543-5082 or 206-616-3636
University of Washington fax: 206-543-0397
Seattle, WA 98195-4350 internet: riches@ms.washington.edu