Re: Getting configure to notice link-time vs run-time failures - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Getting configure to notice link-time vs run-time failures
Date
Msg-id Pine.LNX.4.30.0101190040550.3124-100000@peter.localdomain
Whole thread Raw
In response to Getting configure to notice link-time vs run-time failures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Getting configure to notice link-time vs run-time failures
List pgsql-hackers
Tom Lane writes:

> Gene and I looked into this, and the cause of the misbehavior is this:
> gcc on this installation is set to search /usr/local/lib (along with the
> usual system library directories).  libz.so and libreadline.so are
> indeed in /usr/local/lib, so configure's tests to see if they can be
> linked against will succeed.  But he had LD_LIBRARY_PATH set to a list
> that did *not* include /usr/local/lib, so actually firing up the
> executable would fail.

You get what you pay for.  If you're running executables from configure
you're asking for it.

This setup is a poor man's cross-compilation situation because the system
you're compiling on is not identically configured to the system you're
going to run on.  (Strictly speaking, the behaviour of a test program
might even vary with different LD_LIBRARY_PATH settings.)

So

a)  PostgreSQL does not support cross-compilation (yet).  Too bad.

b)  We could get rid of all executition time checks in configure (to   remedy (a)).  This is one of my plans for the
future.

c)  You could move the execution time checks up before the suspicious   library checks, but I'm afraid that this will
onlycure a particular   symptom and might introduce other problems.
 

I'd say, you're stuck.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: Rob van Nieuwkerk
Date:
Subject: Re: 7.0.3 reproduceable serious select error
Next
From: Peter Eisentraut
Date:
Subject: Re: AW: AW: AW: AW: AW: Re: tinterval - operator problems o n AI X