How to make Fedora4 build threadsafe for Postgresql?

[Matt England]

I received the following problems while trying to build postgresql-8.1.3 on 
FedoraCore4.  Can anyone provide any feedback or suggestions for help?

-Matt
> Date: Tue, 28 Feb 2006 23:34:45 -0600
> To: [e-mail]
> Subject: [PORTS] How to make Fedora4 build threadsafe?
> List-Archive: http://archives.postgresql.org/pgsql-ports
>
> I experienced this error while running this ./configure:
>
> ./configure --enable-thread-safety --prefix=/cgrid/local/postgresql
>
> on FedoraCore4:
>
> checking thread safety of required library functions... no
> configure: error:
> *** Thread test program failed.  Your platform is not thread-safe.
> *** Check the file 'config.log'for the exact reason.
>
> *** You can use the configure option --enable-thread-safety-force
> *** to force threads to be enabled.  However, you must then run
> *** the program in src/tools/thread and add locking function calls
> *** to your applications to guarantee thread safety.
>
> [mengland@localhost postgresql-8.1.3]$
>
> Is there anything I can do to fix this?  Install some extra/different 
> libraries?  (I'm trying a ./configure run after installing 
> "linuxthreads-devel" right now.)
>
> I didn't have this problem building 8.1.0/8.1.1 with the same procedure on 
> Centos4.1 and Debian3.1 (sarge) systems, for whatever that's worth.
>
> -Matt

Date: Tue, 28 Feb 2006 23:57:53 -0600
To: [e-mail]
Subject: Re: [PORTS] How to make Fedora4 build threadsafe?

At 2/28/2006 11:34 PM, Matt England wrote:
> checking thread safety of required library functions... no
> configure: error:
> *** Thread test program failed.  Your platform is not thread-safe.
> *** Check the file 'config.log'for the exact reason.

For what it's worth, this seems to be pertinent part of config.log:

[...]
configure:16424: checking for the pthreads library -lpthreads
configure:16462: gcc -o conftest -O2 -Wall -Wmissing-prototypes 
-Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels 
-fno-strict-aliasing   -D_GNU_SOURCE    conftest.c -lpthreads  -lz 
-lreadline -ltermcap -lcrypt -lresolv -lnsl -ldl -lm -lbsd  >&5
conftest.c: In function 'main':
conftest.c:125: warning: 'th' is used uninitialized in this function
/usr/bin/ld: cannot find -lpthreads
collect2: ld returned 1 exit status
configure:16468: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "PostgreSQL"
[...]

...although the thing is so long that it's hard to tell.

I couldn't find a pthreads library/package/thing anywhere, or at least not 
yet.  My system *does* have a /usr/lib/libpthread.so (singular), but no 
libpthreads (plural).  Installing linuxpthreads-devel didn't solve anything.

Any thoughts?

-Matt

[Paul Howarth]

On Wed, 2006-03-01 at 00:05 -0600, Matt England wrote:
> I received the following problems while trying to build postgresql-8.1.3 on 
> FedoraCore4.  Can anyone provide any feedback or suggestions for help?

The rawhide postgres 8.1.3 package builds thread-safe; why not take the
SRPM and try rebuilding it on FC4?

If you're dead set on building it yourself, you might want to look at
the spec file and see how RedHat do it:

http://cvs.fedora.redhat.com/viewcvs/devel/postgresql/postgresql.spec?view=m...

Paul.

[Matt England]

At 3/1/2006 12:40 AM, Paul Howarth wrote:
> On Wed, 2006-03-01 at 00:05 -0600, Matt England wrote:
> > I received the following problems while trying to build
>
> postgresql-8.1.3 on
> > FedoraCore4.  Can anyone provide any feedback or suggestions for help?
>
> The rawhide postgres 8.1.3 package builds thread-safe; why not take the
> SRPM and try rebuilding it on FC4?

I take it "rawhide" is he codename for FC4?  (I'm ignorant; I'm dealing 
with porting my software to a myriad of OSes across the board.)  Is this an 
appropriate reference:

http://download.fedora.redhat.com/pub/fedora/linux/core/development/s390/rep...

?

And can I confirm via the above docs somewhere that it's built with the 
'./configure --enable-thread-safety' flavor?
> If you're dead set on building it yourself, you might want to look at
> the spec file and see how RedHat do it:
>
> http://cvs.fedora.redhat.com/viewcvs/devel/postgresql/postgresql.spec?view=m...

Ok, thanks Paul for these great references.  I don't yet know redhat/fedora 
spec files/language, but I may learn soon enough if need be.  (I suspect 
this is the stuff needed to write things like .rpm packages, but I'm not sure.)

My main reason for building from source: if my group finds an integration 
problem (or just general bug) when we integrate/embed with postgres, we 
like to be able to address the bug in source and rebuild the integratable 
portion/library/whatever and deliver it to our customers quickly...and we 
don't want to have to wait around when/if said crisis hits and try to poke 
around and figure out how to get the source to build when we are rushing to 
deliver said fix/patch (even if it's a fix on Postgres' behalf which we 
would also push back to Postgres' site).

-Matt

[Paul Howarth]

On Wed, 2006-03-01 at 00:50 -0600, Matt England wrote:
> At 3/1/2006 12:40 AM, Paul Howarth wrote:
> > On Wed, 2006-03-01 at 00:05 -0600, Matt England wrote:
> > > I received the following problems while trying to build
> >
> > postgresql-8.1.3 on
> > > FedoraCore4.  Can anyone provide any feedback or suggestions for help?
> >
> > The rawhide postgres 8.1.3 package builds thread-safe; why not take the
> > SRPM and try rebuilding it on FC4?
>
> I take it "rawhide" is he codename for FC4?  (I'm ignorant; I'm dealing 
> with porting my software to a myriad of OSes across the board.)

No, rawhide is the development branch of Fedora, soon to become FC5.
> Is this an appropriate reference:
>
> http://download.fedora.redhat.com/pub/fedora/linux/core/development/s390/rep...

Partly. That's one of the packages (in this case, for the s390
architecture) built from the postgres SRPM.

The source file you need is:

http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/po...
> And can I confirm via the above docs somewhere that it's built with the 
> './configure --enable-thread-safety' flavor?

Looking at the spec file referenced below, you'll see the following
snippet:

%configure --disable-rpath \
%if %beta
    --enable-debug \
    --enable-cassert \
%endif
%if %plperl
    --with-perl \
%endif
%if %pltcl
    --with-tcl \
    --with-tclconfig=%{_libdir} \
%endif
%if %python
    --with-python \
%endif
%if %ssl
    --with-openssl \
%endif
%if %pam
    --with-pam \
%endif
%if %kerberos
    --with-krb5 \
%endif
%if %nls
    --enable-nls \
%endif
%if %pgfts
    --enable-thread-safety \
%endif
    --sysconfdir=/etc/sysconfig/pgsql \
    --datadir=/usr/share/pgsql \
    --with-docdir=%{_docdir}

RPM macros are used to specify which optional features are to be used, and these are defined higher up the spec file:

%{!?tcldevel:%define tcldevel 1}
%{!?jdbc:%define jdbc 1}
%{!?test:%define test 1}
%{!?python:%define python 1}
%{!?pltcl:%define pltcl 1}
%{!?plperl:%define plperl 1}
%{!?tcl:%define tcl 1}
%{!?pls:%define pls 1}
%{!?ssl:%define ssl 1}
%{!?kerberos:%define kerberos 1}
%{!?nls:%define nls 1}
%{!?xml:%define xml 1}
%{!?pam:%define pam 1}
%{!?pgfts:%define pgfts 1}
%{!?runselftest:%define runselftest 1}

So by default, all of these options (including pgfts) are on.
> > If you're dead set on building it yourself, you might want to look at
> > the spec file and see how RedHat do it:
> >
> > http://cvs.fedora.redhat.com/viewcvs/devel/postgresql/postgresql.spec?view=m...
>
> Ok, thanks Paul for these great references.  I don't yet know redhat/fedora 
> spec files/language, but I may learn soon enough if need be.  (I suspect 
> this is the stuff needed to write things like .rpm packages, but I'm not sure.)

The spec file is the "recipe" for building the RPM package.

http://rpm.org/max-rpm-snapshot/ is a good reference.
> My main reason for building from source: if my group finds an integration 
> problem (or just general bug) when we integrate/embed with postgres, we 
> like to be able to address the bug in source and rebuild the integratable 
> portion/library/whatever and deliver it to our customers quickly...and we 
> don't want to have to wait around when/if said crisis hits and try to poke 
> around and figure out how to get the source to build when we are rushing to 
> deliver said fix/patch (even if it's a fix on Postgres' behalf which we 
> would also push back to Postgres' site).

This sounds like a great reason for learning how to build your own RPM
packages - they're wonderful for shipping pre-built/configured packages
to customers.

Paul.