Thread: build of 7.2.1 on SCO Openserver and Unixware 7.1.1
Sorry for the package, but the following patch need to be applied to get the new verion compiled on SCO Openserver 5.0.5 and Unixware 7.1.1
Attachment
We am going to need an explaination on these changes. Why move the socket test? Why change pow()? The TCL stuff is going to effect other platforms and probably will not be applied without a good reason. --------------------------------------------------------------------------- Nicolas Bazin wrote: > Sorry for the package, but the following patch need to be applied > to get the new verion compiled on SCO Openserver 5.0.5 and > Unixware 7.1.1 [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce,
The reason to move the socket library is that during configuration script
execution, the binary created core dumps if not in the order I gave. You can
check in the port list, some people have been complaining that they could
not even go any further than the configure step and that is the reason.
Here is the message you get otherwise:
checking test program... failed
configure: error:
*** Could not execute a simple test program. This may be a problem
*** related to locating shared libraries. Check the file 'config.log'
*** for the exact reason.
In config.log the last lines are:
configure:7516: checking test program
configure:7525: gcc -o conftest -O2
conftest.c -lz -lPW -lgen -lld -lnsl -lsocket -ldl -lm -lreadline -ltermcap
1>&5
configure: failed program was:
#line 7521 "configure"
#include "confdefs.h"
int main() { return 0; }
pow is in the static library libm and SCO Openserver linker does not accept
to link it in a so file. The modification I provide works whithout changing
the way the code works. If there is another way to get libm linked in so
Here is the message I get:
gcc -shared -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
md5.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
parse.o statement.o tuple.o tuplelist.o dlg_specific.o odbcapi.o
pps.o -lsocket -lnsl -lm -o libpsqlodbc.so.0.27
relocations referenced from file(s) /usr/ccs/lib/libm.a(pow.o) /usr/ccs/lib/libm.a(fmod.o)
/usr/ccs/lib/libm.a(merr.o)fatalerror: relocations remain against allocatable but non-writable
section: .text
collect2: ld returned 1 exit status
The TCL stuff is because Caldera distribution of TCL is compiled with their
compiler. If you happen to use another compiler on your platform (gcc) it
doesn't work anymore. Caldera compiler has -belf -Kpic options which are
fully incompatible with gcc. That's why I though best to leave the TCL
packages been compiled with the compiler used for postgresql.
Note that I have the same issue for perl modules, but I haven't found a
proper way to correct the make files automatically generated. I understand
that we would want the same compilation options but if you install TCL or
PERL from packages you may not have the same compiler.
Appart these points the regression tests work fine for these platforms. They
are still a few warnings during the compilation process, when I get some
time, I'll try to correct them.
Nicolas
----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Nicolas Bazin" <nbazin@ingenico.com.au>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Wednesday, March 27, 2002 12:08 AM
Subject: Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1
>
> We am going to need an explaination on these changes. Why move
> the socket test? Why change pow()? The TCL stuff is going to
> effect other platforms and probably will not be applied without a
> good reason.
>
> --------------------------------------------------------------------------
-
>
> Nicolas Bazin wrote:
> > Sorry for the package, but the following patch need to be applied
> > to get the new verion compiled on SCO Openserver 5.0.5 and
> > Unixware 7.1.1
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
Thanks. This is exactly the detail I needed. Let me comment on each
item.
Nicolas Bazin wrote:
> Bruce,
>
> The reason to move the socket library is that during configuration script
> execution, the binary created core dumps if not in the order I gave. You can
> check in the port list, some people have been complaining that they could
> not even go any further than the configure step and that is the reason.
> Here is the message you get otherwise:
>
> checking test program... failed
> configure: error:
> *** Could not execute a simple test program. This may be a problem
> *** related to locating shared libraries. Check the file 'config.log'
> *** for the exact reason.
>
> In config.log the last lines are:
>
> configure:7516: checking test program
> configure:7525: gcc -o conftest -O2
>
>
>
> conftest.c -lz -lPW -lgen -lld -lnsl -lsocket -ldl -lm -lreadline -ltermcap
> 1>&5
> configure: failed program was:
> #line 7521 "configure"
> #include "confdefs.h"
> int main() { return 0; }
From your link line, it seems -lnls is needed by -lsocket. What I don't
know is whether there are other platforms that where -lnls needs
-lsocket.
... $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS
That last LIBS grows as configure runs, so that is why reordering fixes
things for SCO.
I don't see any immediate downside to moving it so I will apply the
change to 7.3. Any platforms problems with the reordering will show up
during 7.3 beta testing. I would need someone else to agree before
making this change in 7.2.X.
> pow is in the static library libm and SCO Openserver linker does not accept
> to link it in a so file. The modification I provide works whithout changing
> the way the code works. If there is another way to get libm linked in so
> Here is the message I get:
>
> gcc -shared -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o
> columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
> md5.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
> parse.o statement.o tuple.o tuplelist.o dlg_specific.o odbcapi.o
> pps.o -lsocket -lnsl -lm -o libpsqlodbc.so.0.27
> relocations referenced
> from file(s)
> /usr/ccs/lib/libm.a(pow.o)
> /usr/ccs/lib/libm.a(fmod.o)
> /usr/ccs/lib/libm.a(merr.o)
> fatal error: relocations remain against allocatable but non-writable
> section: .text
>
> collect2: ld returned 1 exit status
Yes, the patch replaces pow(8,*) with a lookup table of 4 8^X values.
So SCO provides a library you can't link to? Or you can't mix *.so
libraries and static *.a libraries? I am inclined ot add this patch to
the doc/FAQ_SCO file. We really try to avoid major code uglyness to
work around operating system things that should work on their own.
> The TCL stuff is because Caldera distribution of TCL is compiled with their
> compiler. If you happen to use another compiler on your platform (gcc) it
> doesn't work anymore. Caldera compiler has -belf -Kpic options which are
> fully incompatible with gcc. That's why I though best to leave the TCL
> packages been compiled with the compiler used for postgresql.
>
> Note that I have the same issue for perl modules, but I haven't found a
> proper way to correct the make files automatically generated. I understand
> that we would want the same compilation options but if you install TCL or
> PERL from packages you may not have the same compiler.
Not sure how to deal with this one. Can you add something to FAQ_SCO or
should I add this patch. Clearly this is very OS specific and probably
only true for certain versions of SCO.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Nicolas Bazin" <nbazin@ingenico.com.au>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Wednesday, March 27, 2002 10:21 PM
Subject: Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1
>
> Thanks. This is exactly the detail I needed. Let me comment on each
> item.
>
>
> Nicolas Bazin wrote:
> > Bruce,
> >
> > The reason to move the socket library is that during configuration
script
> > execution, the binary created core dumps if not in the order I gave. You
can
> > check in the port list, some people have been complaining that they
could
> > not even go any further than the configure step and that is the reason.
> > Here is the message you get otherwise:
> >
> > checking test program... failed
> > configure: error:
> > *** Could not execute a simple test program. This may be a problem
> > *** related to locating shared libraries. Check the file 'config.log'
> > *** for the exact reason.
> >
> > In config.log the last lines are:
> >
> > configure:7516: checking test program
> > configure:7525: gcc -o conftest -O2
> >
> >
> >
> >conftest.c -lz -lPW -lgen -lld -lnsl -lsocket -ldl -lm -lreadline -ltermcap
> > 1>&5
> > configure: failed program was:
> > #line 7521 "configure"
> > #include "confdefs.h"
> > int main() { return 0; }
>
> From your link line, it seems -lnls is needed by -lsocket. What I don't
> know is whether there are other platforms that where -lnls needs
> -lsocket.
>
> ... $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS
>
> That last LIBS grows as configure runs, so that is why reordering fixes
> things for SCO.
>
> I don't see any immediate downside to moving it so I will apply the
> change to 7.3. Any platforms problems with the reordering will show up
> during 7.3 beta testing. I would need someone else to agree before
> making this change in 7.2.X.
The other possibility is to have configure to test the order of the library,
then there won't be any effect on any platform.
Try the existing order, if it fails try the other order.
>
>
> > pow is in the static library libm and SCO Openserver linker does not
accept
> > to link it in a so file. The modification I provide works whithout
changing
> > the way the code works. If there is another way to get libm linked in so
> > Here is the message I get:
> >
> > gcc -shared -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o
bind.o
> > columninfo.o connection.o convert.o drvconn.o environ.o execute.o lobj.o
> > md5.o misc.o options.o pgtypes.o psqlodbc.o qresult.o results.o socket.o
> > parse.o statement.o tuple.o tuplelist.o dlg_specific.o odbcapi.o
> > pps.o -lsocket -lnsl -lm -o libpsqlodbc.so.0.27
> > relocations referenced
> > from file(s)
> > /usr/ccs/lib/libm.a(pow.o)
> > /usr/ccs/lib/libm.a(fmod.o)
> > /usr/ccs/lib/libm.a(merr.o)
> > fatal error: relocations remain against allocatable but non-writable
> > section: .text
> >
> > collect2: ld returned 1 exit status
>
> Yes, the patch replaces pow(8,*) with a lookup table of 4 8^X values.
> So SCO provides a library you can't link to? Or you can't mix *.so
> libraries and static *.a libraries? I am inclined ot add this patch to
> the doc/FAQ_SCO file. We really try to avoid major code uglyness to
> work around operating system things that should work on their own.
>
My guess is that this library has not been compiled as a pic code then it's
not relocatable. This must be a bug in SCO, and I only have seen this
problem with libm only yet.
>
>
> > The TCL stuff is because Caldera distribution of TCL is compiled with
their
> > compiler. If you happen to use another compiler on your platform (gcc)
it
> > doesn't work anymore. Caldera compiler has -belf -Kpic options which are
> > fully incompatible with gcc. That's why I though best to leave the TCL
> > packages been compiled with the compiler used for postgresql.
> >
> > Note that I have the same issue for perl modules, but I haven't found a
> > proper way to correct the make files automatically generated. I
understand
> > that we would want the same compilation options but if you install TCL
or
> > PERL from packages you may not have the same compiler.
>
> Not sure how to deal with this one. Can you add something to FAQ_SCO or
> should I add this patch. Clearly this is very OS specific and probably
> only true for certain versions of SCO.
>
I don't know much about other platforms. This is more a compiler
incompatibility then a platform problem. The problem comes from the fact
that one compiler was used to create a package and another one is used to
compile postgres. I know that your are supposed to be able to recompile the
code you installl on your server, but first sometimes it helps using
preconfigured packages and also it may not be so easy to recompile from the
public distribution that may need specific patches.
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@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
>
>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, the patch replaces pow(8,*) with a lookup table of 4 8^X values.
> So SCO provides a library you can't link to? Or you can't mix *.so
> libraries and static *.a libraries? I am inclined ot add this patch to
> the doc/FAQ_SCO file. We really try to avoid major code uglyness to
> work around operating system things that should work on their own.
Actually, the existing coding in odbc is just plain stupid: why are we
using a transcendental function call to emulate an integer shift?
Even the table-based implementation that Nicolas proposed is doing it
the hard way. Try converting, eg,
for (i = 1; i <= 3; i++) y += (s[i] - 48) * (int) pow(8, 3 - i);
to
for (i = 1; i <= 3; i++) y += (s[i] - '0') << (3 * (3 - i));
and you can get the patch accepted just on efficiency and readability
grounds, never mind whether it avoids SCO library breakage.
>> The TCL stuff is because Caldera distribution of TCL is compiled with their
>> compiler. If you happen to use another compiler on your platform (gcc) it
>> doesn't work anymore. Caldera compiler has -belf -Kpic options which are
>> fully incompatible with gcc. That's why I though best to leave the TCL
>> packages been compiled with the compiler used for postgresql.
We've been around on this a couple of times now; the current theory is
that we should stop using the TCL-supplied switches altogether. There
is a patch in the works to change libpgtcl and pltcl to be built the
same way we build everything else in the distribution.
regards, tom lane
----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Bruce Momjian" <pgman@candle.pha.pa.us> Cc: "Nicolas Bazin" <nbazin@ingenico.com.au>; "PostgreSQL-development" <pgsql-hackers@postgresql.org> Sent: Thursday, March 28, 2002 2:30 AM Subject: Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware 7.1.1 > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Yes, the patch replaces pow(8,*) with a lookup table of 4 8^X values. > > So SCO provides a library you can't link to? Or you can't mix *.so > > libraries and static *.a libraries? I am inclined ot add this patch to > > the doc/FAQ_SCO file. We really try to avoid major code uglyness to > > work around operating system things that should work on their own. > > Actually, the existing coding in odbc is just plain stupid: why are we > using a transcendental function call to emulate an integer shift? > Even the table-based implementation that Nicolas proposed is doing it > the hard way. Try converting, eg, > > for (i = 1; i <= 3; i++) > y += (s[i] - 48) * (int) pow(8, 3 - i); > > to > > for (i = 1; i <= 3; i++) > y += (s[i] - '0') << (3 * (3 - i)); > > and you can get the patch accepted just on efficiency and readability > grounds, never mind whether it avoids SCO library breakage. > > >> The TCL stuff is because Caldera distribution of TCL is compiled with their > >> compiler. If you happen to use another compiler on your platform (gcc) it > >> doesn't work anymore. Caldera compiler has -belf -Kpic options which are > >> fully incompatible with gcc. That's why I though best to leave the TCL > >> packages been compiled with the compiler used for postgresql. > > We've been around on this a couple of times now; the current theory is > that we should stop using the TCL-supplied switches altogether. There > is a patch in the works to change libpgtcl and pltcl to be built the > same way we build everything else in the distribution. Perls modules have the same problems. Is there a patch also ? > > regards, tom lane > >
Updated version applied. Thanks. --------------------------------------------------------------------------- Nicolas Bazin wrote: > Sorry for the package, but the following patch need to be applied to get the new verion compiled on SCO Openserver 5.0.5and Unixware 7.1.1 [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026