Thread: Re: 7.1.3 fails to configure on Solaris 2.7

At 3:23 PM -0800 12/4/01, Henry B. Hotz wrote:
>At 8:26 PM -0500 12/3/01, Tom Lane wrote:
>>"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
>>>  configure: failed program was:
>>>  #line 6802 "configure"
>>>  #include "confdefs.h"
>>>  int main() { return 0; }
>>
>>>  I can put those 3 lines in a file and use those gcc options and it
>>>  compiles just fine thank you.
>>
>>But does it *execute*?  And return zero status?
>>
>>The usual cause of this sort of problem is messed-up shared library
>>linkage (eg, LD_LIBRARY_PATH different from linker's search path),
>>which doesn't show up till you try to execute the program.
>>That's what the test is there to catch.
>
>Ah!  No it doesn't.  It can't find /usr/local/lib/libz.so.  Let's
>see there is a configure option for that isn't there?  Setting
>LD_RUN_PATH or something. . .

OK, --with-libs=/usr/local/lib doesn't work;  --enable-rpath  doesn't
work.  Setting LD_RUN_PATH does.

Seems like this should be mentioned in the INSTALL notes.  Actually
seems like this should be taken care of automatically, but maybe
that's hard?
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu

Henry B. Hotz writes:

> >Ah!  No it doesn't.  It can't find /usr/local/lib/libz.so.  Let's
> >see there is a configure option for that isn't there?  Setting
> >LD_RUN_PATH or something. . .
>
> OK, --with-libs=/usr/local/lib doesn't work;  --enable-rpath  doesn't
> work.  Setting LD_RUN_PATH does.
>
> Seems like this should be mentioned in the INSTALL notes.  Actually
> seems like this should be taken care of automatically, but maybe
> that's hard?

It should be taken care of automatically by the operating system.  It's
not the task of PostgreSQL to tell your operating system how to find
shared libraries, or to override its decisions.  We can only tell you when
something is (probably) wrong.

IMHO, the setup that the link editor can find a library but the run time
linker cannot is simply broken, but the choice how to fix it is yours.

--
Peter Eisentraut   peter_e@gmx.net

At 5:38 PM +0100 12/6/01, Peter Eisentraut wrote:
>Henry B. Hotz writes:
>
>>  >Ah!  No it doesn't.  It can't find /usr/local/lib/libz.so.  Let's
>>  >see there is a configure option for that isn't there?  Setting
>>  >LD_RUN_PATH or something. . .
>>
>>  OK, --with-libs=/usr/local/lib doesn't work;  --enable-rpath  doesn't
>>  work.  Setting LD_RUN_PATH does.
>>
>>  Seems like this should be mentioned in the INSTALL notes.  Actually
>>  seems like this should be taken care of automatically, but maybe
>>  that's hard?
>
>It should be taken care of automatically by the operating system.  It's
>not the task of PostgreSQL to tell your operating system how to find
>shared libraries, or to override its decisions.  We can only tell you when
>something is (probably) wrong.
>
>IMHO, the setup that the link editor can find a library but the run time
>linker cannot is simply broken, but the choice how to fix it is yours.

I couldn't agree more.

However I didn't need to do anything like that to build/install
openssl, openssh, tcl, tk, zlib, readline, enscript, or pcre.  So why
do I have to manually set LD_RUN_PATH for postgres?

Incidentally I got it to build and pass regression tests with
--prefix=/usr/local -with-tcl --with-perl -with-openssl --with-CXX
--enable-syslog.  I did have to do the /etc/system thing to increase
shared memory.  (I don't expect you to fix that one for me.  *sigh*)
Now on to getting the server properly configured. . .
--
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu