Re: Getting configure to notice link-time vs run-time failures
От | Peter Eisentraut |
---|---|
Тема | Re: Getting configure to notice link-time vs run-time failures |
Дата | |
Msg-id | Pine.LNX.4.30.0101190040550.3124-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Getting configure to notice link-time vs run-time failures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Getting configure to notice link-time vs run-time failures
|
Список | 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 по дате отправления: