Fri, Nov 09, 2007 at 12:17:42PM +0100, Zdenek Kotala:
> heasley wrote:
> >Thu, Nov 08, 2007 at 11:04:01AM +0100, Zdenek Kotala:
> >>heasley napsal(a):
> 
> >
> >The configure is via NetBSD's pkgsrc system.
> >
> >./configure --sysconfdir=/usr/pkg/etc/postgresql 
> >--datadir=/usr/pkg/share/po
> >stgresql --with-docdir=/usr/pkg/share/doc/postgresql 
> >--with-template=solaris --w
> >ithout-readline --without-zlib --enable-nls --without-java --without-perl 
> >--with
> >out-python --without-tcl --with-openssl --with-readline --with-zlib 
> >--enable-thr
> >ead-safety --with-libiconv-prefix=/usr/pkg --with-libintl-prefix=/usr/pkg 
> >--pref
> >ix=/usr/pkg --host=sparc-sun-solaris2 --mandir=/usr/pkg/man
> 
> It is really strange configure. See --with-readline/--without-readline.
> Unfrotunately I currently does not have system with S9 similar to yours 
> configuration :(. I tested Sun Studio compiler with following configure 
> switch ./configure --without-readline --enable-thread-safety and it 
> works fine. Can you try Sun studio?
> 
> http://developers.sun.com/sunstudio/downloads/thankyou.jsp?submit=%A0FREE+Download%A0%BB%A0
> 
> >from config.log:
> >CFLAGS=-g -static-libgcc -static-libgcc -D_LARGEFILE64_SOURCE -mcpu=v9 
> >-mtune=ultrasparc -m64 -D__sparc_v9__ -pipe -I/usr/pkg/include 
> >-I/usr/include -Wall -Wmissing-prototypes -Wpointer-arith -Winline 
> >-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing
> 
> Can you try build it as 32bit application? If there is not problem with 
> 64bit libraries.

sort of; I do not have 32bit readline, openssl, etc. and I do not have
sunstudio ATM [sorry, I have very little free time].  I can try sunCC
later.

just using gcc, outside of the pkgsrc system, it will still be 64-bit
(since I have a wrapper around gcc that forces the 64bit options), it
builds.  But, this success is an accident.  It claims to be "checking
without flags", but in fact it has -pthread [from where?].

configure:16405: checking whether pthreads work without any flags
configure:16498: gcc -o conftest -g -static-libgcc -Wall -Wmissing-prototypes -W
pointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-
aliasing -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after
-statement -Wendif-labels -fno-strict-aliasing  -pthread -pthreads       conftes
t.c   -lpthread      -lz -lrt -lresolv -lgen -lsocket -lnsl -ldl -lm  >&5
configure:16504: $? = 0
configure:16508: test -z 
                         || test ! -s conftest.err
configure:16511: $? = 0
configure:16514: test -s conftest
configure:16517: $? = 0
configure:16555: result: yes

www.shrubbery.net/~heas/pg_config.log2.txt

> >www.shrubbery.net/~heas/pg_config.log.txt
> >www.shrubbery.net/~heas/conftest.c.txt
> >
> >I built gcc 4.1, after having some difficulty with other versions.  It is a
> >fairly straight forward build, expect that it has a hack to avoid a 
> >libiconv
> >bug and is within a wrapper script that forces 64-bit options.  I did not 
> >have
> >this problem with pre-8.1.5 postgres as I recall; 8.1.4 built fine and I do
> >not believe there have been any pkgsrc changes that would affect this.
> 
> I don't see any difference in ./configure related to pthread. Do you use 
> same process for building? Do you have same version of all libraries, 
> GCC or did you update some version? Can you compile 8.1.4 with same 
> configuration?

yes, it does build, but for the reason as below.

> It seems to me that it could be something wrong with your GCC compilation.

I wouldn't put anything past gcc, but I do not think it is at fault here.
My understanding, at least for NetBSD, FreeBSD and Solaris, is that they
all require -pthread; which essentially adds -lpthread.  So, unless you
have some dependency that picks-up libpthread, you get these bogus (I
agree) stubs from libc which I'd suspect are the cause of the spinning.

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Reply via email to