Re: Psycopg 1.1.9+, Postgresql 7.4, Mac OS X 10.3.1 won't configure

> OK, I haven't configured psycopg on OS X recently, but I did notice 
> some annoying things in the postgresql 7.4 compilation.  In fact it 
> applies to my current pg 7.3.x installation too.
> Mac OS X uses Mach-O format for binary files which is quite a bit 
> different than the ELF format used on linux, solaris, FreeBSD, etc.  
> The proper extension for dynamic libraries is *.dylib, so the libpq.so 
> name is wrong and the linker will never find it.  The next problem is 
> that OS X makes a distinction between dynamic libraries and loadable 
> bundles, and the postgresql folks built all "shared objects" in bundle 
> format.  The binary formats are different and can not be interchanged. 
>  Things like plperl and plpgsql should be bundles on Mac OS X and they 
> are.  (The filename doesn't matter for bundles; it can be anything the 
> application likes.)  Things like libpq and libecpg that are linked 
> against at build time should be dylibs, and they are not.  So, 
> basically the linker can not find a dynamic library (libpq.dylib) and 
> even if you renamed libpq.so it would still fail because the file type 
> is wrong.
> Aha!  What about regular old static archives?  There is a libpq.a file 
> in there too, or there should be.  I'll bet that the table of contents 
> is out of date.  Mac OS X is persnickity about that too.
> Try 'ranlib /usr/local/lib/libpq.a' then try to configure psycopg.
Thank you, Chris, for your help.  Unfortunately, it didn't work.  I 
keep getting the same error, psycopg's configure goes to check for 
PQconnectStart, and fails.
The root of the problem, then, is that the postgresql configure process 
specifies that the shared objects it builds will be built in bundle 
format, when they should be building some of them, specifically the 
lib* files, as dylibs.  Correct?  If that's the case, then what we need 
is to figure out how to compile those lib* files as dylibs rather than 
as bundles.  Is that an accurate problem statement?  And then we 
should, for completeness' sake, figure out how to modify the postgres 
configure scripts so that, on Darwin platforms, they continue to build 
the lib* files as dylibs, submit it to postgres and be done with it all 
(until the next time Apple decides to break backwards compatibility).
Part of the problem is that Postgres itself builds and runs fine on OS 
X as it stands, and thus the postgres developers have very little 
motivation to fix the ancillary problems of those of us who want to use 
it on OS X.  The fact that Apple presents a moving target for the 
"right way" to do all this doesn't help, either.
So, is that an accurate statement of the current state of affairs?  If 
so, I'll do what I can to see if I can rectify the situation.  It will 
probably take me a while, but it looks like a worthy goal, at least.
Thanks again,

---Peter