Re: build of 7.2.1 on SCO Openserver and Unixware 7.1.1

----- Original Message -----
From: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
>