Обсуждение: UnixWare/CVS Tip/initdb.c needs to use threads flags...
I attempted(!) to compile up CVS Head, and if you --enable-thread-safety, you need to include the THREADS stuff to cc: gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport -o initdb Undefined first referenced symbol in file pthread_getspecific libpq.so pthread_key_create libpq.so pthread_once libpq.so pthread_setspecific libpq.so UX:ld: ERROR: Symbol referencing errors. No output written to initdb gmake[3]: *** [initdb] Error 1 gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin/initdb' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql/src/bin' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/src' gmake: *** [all] Error 2 $ Otherwise we don't pick up the threads library where the pthread_* routines are defined. (I sent the defines we need in src/template/unixware to Bruce already). -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Thu, 18 Mar 2004, Larry Rosenman wrote: > I attempted(!) to compile up CVS Head, and if you --enable-thread-safety, > you need to include the THREADS stuff to cc: > > gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' > cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq > -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz > -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport > -o initdb > Undefined first referenced > symbol in file > pthread_getspecific libpq.so > pthread_key_create libpq.so > pthread_once libpq.so > pthread_setspecific libpq.so > UX:ld: ERROR: Symbol referencing errors. No output written to initdb > gmake[3]: *** [initdb] Error 1 I bring this up on PGHACKERS because unixware may not be the only place we have to use the threads flags. What is the concensus of the community? LER
Larry Rosenman <ler@lerctr.org> writes:
> What is the concensus of the community?
AFAICS, initdb should not need to depend on libpq in the first place;
it never makes a connection to a live postmaster. I think it would be
cleaner to get rid of that dependency instead of propagating thread junk
into initdb.
regards, tom lane
--On Thursday, March 18, 2004 19:39:56 -0500 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Larry Rosenman <ler@lerctr.org> writes: >> What is the concensus of the community? > > AFAICS, initdb should not need to depend on libpq in the first place; > it never makes a connection to a live postmaster. I think it would be > cleaner to get rid of that dependency instead of propagating thread junk > into initdb. That's why I asked :) LER > > regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > On Thu, 18 Mar 2004, Larry Rosenman wrote: > > > I attempted(!) to compile up CVS Head, and if you --enable-thread-safety, > > you need to include the THREADS stuff to cc: > > > > gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' > > cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq > > -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz > > -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm -lpgport > > -o initdb > > Undefined first referenced > > symbol in file > > pthread_getspecific libpq.so > > pthread_key_create libpq.so > > pthread_once libpq.so > > pthread_setspecific libpq.so > > UX:ld: ERROR: Symbol referencing errors. No output written to initdb > > gmake[3]: *** [initdb] Error 1 > I bring this up on PGHACKERS because unixware may not be the only > place we have to use the threads flags. > > What is the concensus of the community? I tried removing the libpq link for initdb and got:(3) gmakegmake -C ../../../src/interfaces/libpq allgmake[1]: Enteringdirectory`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq'gmake[1]: Nothing to be done for `all'.gmake[1]:Leaving directory`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq'gmake -C ../../../src/portallgmake[1]: Entering directory`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port'gmake[1]: Nothing tobe done for `all'.gmake[1]: Leaving directory`/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port'gcc -O2 -fno-strict-aliasing-Wall -Wmissing-prototypes-Wmissing-declarations -O1 -Wall -Wmissing-prototypes-Wmissing-declarations-Wpointer-arith -Wcast-align initdb.o-L../../../src/port -L/usr/local/lib -L/usr/contrib/lib-Wl,-rpath,/usr/local/pgsql/lib-O1 -Wall -Wmissing-prototypes-Wmissing-declarations -Wpointer-arith -Wcast-align-lssl -lcrypto -lz-lreadline -ltermcap -lgetopt -lcompat -lipc -ldl -lm -lutil -lpgport-o initdbinitdb.o: Infunction `get_encoding_id':initdb.o(.text+0x739): undefined reference to `pg_char_to_encoding'initdb.o(.text+0x74b): undefinedreference to `pg_valid_server_encoding'initdb.o: In function `trapsig':initdb.o(.text+0x2212): undefined referenceto `pqsignal'initdb.o: In function `main':initdb.o(.text+0x2e69): undefined reference to `pqsignal'initdb.o(.text+0x2e7b):undefined reference to `pqsignal'initdb.o(.text+0x2e8a): undefined reference to `pqsignal'initdb.o(.text+0x2e9c):undefined reference to `pqsignal'initdb.o(.text+0x2ea8): more undefined references to `pqsignal'followgmake: *** [initdb] Error 1 I thought that once you include libpthread in libpq, that you don't have to mention it again then you use libpq. Is your platform different somehow in this regard? I seem to remember this problem with libcrypt and libpq. Is this the same problem? I see that initdb is just the first of many /bin programs to be compiled, so if we have to add the thread lib, we will have to do it for all the bin programs. Yikes. Why wasn't this a problem for 7.4? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
--On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Larry Rosenman wrote: >> On Thu, 18 Mar 2004, Larry Rosenman wrote: >> >> > I attempted(!) to compile up CVS Head, and if you >> > --enable-thread-safety, you need to include the THREADS stuff to cc: >> > >> > gmake[4]: Leaving directory `/home/ler/pg-dev/pgsql/src/port' >> > cc -O -Kinline initdb.o -L../../../src/interfaces/libpq -lpq >> > -L../../../src/port -L/usr/local/lib -Wl,-R/usr/local/pgsql/lib -lz >> > -lreadline -ltermcap -lresolv -lgen -lld -lsocket -lnsl -ldl -lm >> > -lpgport -o initdb >> > Undefined first referenced >> > symbol in file >> > pthread_getspecific libpq.so >> > pthread_key_create libpq.so >> > pthread_once libpq.so >> > pthread_setspecific libpq.so >> > UX:ld: ERROR: Symbol referencing errors. No output written to initdb >> > gmake[3]: *** [initdb] Error 1 >> I bring this up on PGHACKERS because unixware may not be the only >> place we have to use the threads flags. >> >> What is the concensus of the community? > > I tried removing the libpq link for initdb and got: > > (3) gmake > gmake -C ../../../src/interfaces/libpq all > gmake[1]: Entering directory > `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq' > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory > `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/interfaces/libpq' > gmake -C ../../../src/port all > gmake[1]: Entering directory > `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port' > gmake[1]: Nothing to be done for `all'. > gmake[1]: Leaving directory > `/usr/var/local/src/gen/pgsql/CURRENT/pgsql/src/port' > gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes > -Wmissing-declarations -O1 -Wall -Wmissing-prototypes > -Wmissing-declarations -Wpointer-arith -Wcast-align initdb.o > -L../../../src/port -L/usr/local/lib -L/usr/contrib/lib > -Wl,-rpath,/usr/local/pgsql/lib -O1 -Wall -Wmissing-prototypes > -Wmissing-declarations -Wpointer-arith -Wcast-align -lssl -lcrypto -lz > -lreadline -ltermcap -lgetopt -lcompat -lipc -ldl -lm -lutil -lpgport > -o initdb > initdb.o: In function `get_encoding_id': > initdb.o(.text+0x739): undefined reference to `pg_char_to_encoding' > initdb.o(.text+0x74b): undefined reference to `pg_valid_server_encoding' > initdb.o: In function `trapsig': > initdb.o(.text+0x2212): undefined reference to `pqsignal' > initdb.o: In function `main': > initdb.o(.text+0x2e69): undefined reference to `pqsignal' > initdb.o(.text+0x2e7b): undefined reference to `pqsignal' > initdb.o(.text+0x2e8a): undefined reference to `pqsignal' > initdb.o(.text+0x2e9c): undefined reference to `pqsignal' > initdb.o(.text+0x2ea8): more undefined references to `pqsignal' follow > gmake: *** [initdb] Error 1 > > I thought that once you include libpthread in libpq, that you don't have > to mention it again then you use libpq. Is your platform different > somehow in this regard? > > I seem to remember this problem with libcrypt and libpq. Is this the > same problem? > > I see that initdb is just the first of many /bin programs to be > compiled, so if we have to add the thread lib, we will have to do it for > all the bin programs. Yikes. Why wasn't this a problem for 7.4? 7.4 had initdb as a Shell Script. the 7.4.x libpq didn't have any pthread_* references in it, that I see on my box. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
--On Thursday, March 18, 2004 22:47:39 -0600 Larry Rosenman <ler@lerctr.org> wrote: > > > --On Thursday, March 18, 2004 23:03:16 -0500 Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > >> I see that initdb is just the first of many /bin programs to be >> compiled, so if we have to add the thread lib, we will have to do it for >> all the bin programs. Yikes. Why wasn't this a problem for 7.4? > 7.4 had initdb as a Shell Script. > the 7.4.x libpq didn't have any pthread_* references in it, that I see > on my box. more info: /home/ler/pg-prod/postgresql-7.4.2/src/interfaces/libpq: $ grep pthread_ *.c thread.c: * strerror(). Other operating systems use pthread_setspecific() thread.c: * and pthread_getspecific() internally to allow standard library thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r versions thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific() to return thread.c: static pthread_mutex_t strerror_lock = PTHREAD_MUTEX_INITIALIZER; thread.c: pthread_mutex_lock(&strerror_lock); thread.c: pthread_mutex_unlock(&strerror_lock); thread.c: static pthread_mutex_t getpwuid_lock = PTHREAD_MUTEX_INITIALIZER; thread.c: pthread_mutex_lock(&getpwuid_lock); thread.c: pthread_mutex_unlock(&getpwuid_lock); thread.c: static pthread_mutex_t gethostbyname_lock = PTHREAD_MUTEX_INITIALIZER; thread.c: pthread_mutex_lock(&gethostbyname_lock); thread.c: pthread_mutex_unlock(&gethostbyname_lock); $ nm libpq.so | grep pthread $ /home/ler/pg-dev/pgsql-server/src/interfaces/libpq: (7.5-dev): $ nm libpq.so | grep pthread_ [271] |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_getspecific [370] |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_key_create [421] |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_once [434] |0 |0 |NOTY |GLOB |0 |UNDEF |pthread_setspecific $ grep pthread_ *.c fe-connect.c: static pthread_once_t check_sigpipe_once = PTHREAD_ONCE_INIT; fe-connect.c: pthread_once(&check_sigpipe_once, check_sigpipe_handler); fe-print.c: pthread_setspecific(thread_in_send, "t"); fe-print.c: pthread_setspecific(thread_in_send, "f"); fe-secure.c:pthread_key_t thread_in_send; fe-secure.c: pthread_setspecific(thread_in_send, "t"); fe-secure.c: pthread_setspecific(thread_in_send, "f"); fe-secure.c: pthread_key_create(&thread_in_send, NULL); fe-secure.c: return (pthread_getspecific(thread_in_send) /* has it been set? */ && fe-secure.c: *(char *)pthread_getspecific(thread_in_send) == 't') ? true : false; thread.c: * strerror(). Other operating systems use pthread_setspecific() thread.c: * and pthread_getspecific() internally to allow standard library thread.c: * use pthread_setspecific/pthread_getspecific() also have *_r versions thread.c: * getpwuid() calls pthread_setspecific/pthread_getspecific() to return $ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > > I thought that once you include libpthread in libpq, that you don't have > > to mention it again then you use libpq. Is your platform different > > somehow in this regard? > > > > I seem to remember this problem with libcrypt and libpq. Is this the > > same problem? > > > > I see that initdb is just the first of many /bin programs to be > > compiled, so if we have to add the thread lib, we will have to do it for > > all the bin programs. Yikes. Why wasn't this a problem for 7.4? > 7.4 had initdb as a Shell Script. > the 7.4.x libpq didn't have any pthread_* references in it, that I see > on my box. Ah, yes. We added the thread-local storage to handle SIGPIPE. The problem is that initdb isn't the only place. If you comment out initdb from the Makefile in src/bin, does the next make fail too? I bet it does. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073