Обсуждение: libpq and libecpg problems on MacOs-X (Panther/10.3.3)
When trying to use postgresql on my MacOS-X system (10.3.3) I encountered the problem that the libecpg and libpq dynamic libraries could not be linked into my applications. Upon investigation, it turns out that the postgresql libraries on MacOS-X/Darwin are being built as 'bundles' ... which means that you can dynamically load them into a running program using the dlopen() api, but you can't link them at application build time. This may be correct behavior for some of the modules in postgres (eg the perl module), but is certainly wrong for libecpg and libpq ... which are meant to be linked with C (and other language) applications. I attach a patch which fixes this for MacOS-X 10.3.3, by altering the makefiles to understand the two ways of building a library/bundle and having a variable setting 'BUNDLE=no' to day that the normal dynamic library should be built rather than a bundle. The patch alters the libecpg and libpq makefiles to set this variable, so these two are built as normal dynamic libraries, while the other code continues to be built as bundles. Probably there are other parts of the system which should not be bundles either ... but I don't use them so I don't know. Possibly behavior differs in older versions of MacOS-X ... again, I don't have the old systems so I don't know.
Вложения
Richard Frith-Macdonald wrote: > When trying to use postgresql on my MacOS-X system (10.3.3) I > encountered the problem that the libecpg and libpq dynamic libraries > could not be linked into my applications. > > Upon investigation, it turns out that the postgresql libraries on > MacOS-X/Darwin are being built as 'bundles' ... which means that you > can dynamically load them into a running program using the dlopen() > api, but you can't link them at application build time. This may be > correct behavior for some of the modules in postgres (eg the perl > module), but is certainly wrong for libecpg and libpq ... which are > meant to be linked with C (and other language) applications. > > I attach a patch which fixes this for MacOS-X 10.3.3, by altering the > makefiles to understand the two ways of building a library/bundle and > having a variable setting 'BUNDLE=no' to day that the normal dynamic > library should be built rather than a bundle. The patch alters the > libecpg and libpq makefiles to set this variable, so these two are > built as normal dynamic libraries, while the other code continues to be > built as bundles. > > Probably there are other parts of the system which should not be > bundles either ... but I don't use them so I don't know. > Possibly behavior differs in older versions of MacOS-X ... again, I > don't have the old systems so I don't know. This sounds very strange. If you can't link libpq into your application, why can psql link in libpq? I am going to need another MacOSX person to comment on this before applying this change because I thought things were fine on OS X. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Richard Frith-Macdonald wrote: > I attach a patch which fixes this for MacOS-X 10.3.3, by altering the > makefiles to understand the two ways of building a library/bundle and > having a variable setting 'BUNDLE=no' to day that the normal dynamic > library should be built rather than a bundle. The patch alters the > libecpg and libpq makefiles to set this variable, so these two are built > as normal dynamic libraries, while the other code continues to be built > as bundles. This is essentially doing the same thing as patch I'd sent back in the day that (I thought) was going to get into the next release, but I'd never had a chance to follow up on it. (What I think is) the original thread is here: http://archives.postgresql.org/pgsql-bugs/2003-01/msg00005.php ...my patch isn't at the link given anymore, but the latest version of it is here: http://cvs.sourceforge.net/viewcvs.py/fink/dists/10.3/unstable/crypto/finkinfo/postgresql-ssl.patch?rev=HEAD The current behavior *is* broken; things work only because everything ends up linking statically against the .a's, and the bundles are basically dead weight. -- Benjamin Reed, a.k.a. RangerRick ranger@befunk.com / http://ranger.befunk.com/
Benjamin Reed wrote: > Richard Frith-Macdonald wrote: > > > I attach a patch which fixes this for MacOS-X 10.3.3, by altering the > > makefiles to understand the two ways of building a library/bundle and > > having a variable setting 'BUNDLE=no' to day that the normal dynamic > > library should be built rather than a bundle. The patch alters the > > libecpg and libpq makefiles to set this variable, so these two are built > > as normal dynamic libraries, while the other code continues to be built > > as bundles. > > This is essentially doing the same thing as patch I'd sent back in the > day that (I thought) was going to get into the next release, but I'd > never had a chance to follow up on it. > > (What I think is) the original thread is here: > > http://archives.postgresql.org/pgsql-bugs/2003-01/msg00005.php > > ...my patch isn't at the link given anymore, but the latest version of > it is here: > > http://cvs.sourceforge.net/viewcvs.py/fink/dists/10.3/unstable/crypto/finkinfo/postgresql-ssl.patch?rev=HEAD > > The current behavior *is* broken; things work only because everything > ends up linking statically against the .a's, and the bundles are > basically dead weight. OK, that's all I need to hear. I will make the changes for 7.5. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
[ Will exclude thead stuff becaues it is not needed anymore.]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---------------------------------------------------------------------------
Richard Frith-Macdonald wrote:
> When trying to use postgresql on my MacOS-X system (10.3.3) I
> encountered the problem that the libecpg and libpq dynamic libraries
> could not be linked into my applications.
>
> Upon investigation, it turns out that the postgresql libraries on
> MacOS-X/Darwin are being built as 'bundles' ... which means that you
> can dynamically load them into a running program using the dlopen()
> api, but you can't link them at application build time. This may be
> correct behavior for some of the modules in postgres (eg the perl
> module), but is certainly wrong for libecpg and libpq ... which are
> meant to be linked with C (and other language) applications.
>
> I attach a patch which fixes this for MacOS-X 10.3.3, by altering the
> makefiles to understand the two ways of building a library/bundle and
> having a variable setting 'BUNDLE=no' to day that the normal dynamic
> library should be built rather than a bundle. The patch alters the
> libecpg and libpq makefiles to set this variable, so these two are
> built as normal dynamic libraries, while the other code continues to be
> built as bundles.
>
> Probably there are other parts of the system which should not be
> bundles either ... but I don't use them so I don't know.
> Possibly behavior differs in older versions of MacOS-X ... again, I
> don't have the old systems so I don't know.
>
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Your patch has been added to the PostgreSQL unapplied patches list at:
ISTM we had specifically rejected the prior version of this (the one
from Ben Reed) for some reason, which I do not recall at the moment.
If the archives were up, I'd go look, but in the meantime please do
not apply.
regards, tom lane
Tom Lane wrote: > ISTM we had specifically rejected the prior version of this (the one > from Ben Reed) for some reason, which I do not recall at the moment. > If the archives were up, I'd go look, but in the meantime please do > not apply. I had thought it was only because the "marking something as a module or not" thing was a big change and needed more review, but honestly I don't recall either, and I was having trouble finding the previous discussion in list archives. -- Benjamin Reed, a.k.a. RangerRick ranger@befunk.com / http://ranger.befunk.com/
FYI, Tom is still researching this. It will be resolved in 7.5. --------------------------------------------------------------------------- Richard Frith-Macdonald wrote: > When trying to use postgresql on my MacOS-X system (10.3.3) I > encountered the problem that the libecpg and libpq dynamic libraries > could not be linked into my applications. > > Upon investigation, it turns out that the postgresql libraries on > MacOS-X/Darwin are being built as 'bundles' ... which means that you > can dynamically load them into a running program using the dlopen() > api, but you can't link them at application build time. This may be > correct behavior for some of the modules in postgres (eg the perl > module), but is certainly wrong for libecpg and libpq ... which are > meant to be linked with C (and other language) applications. > > I attach a patch which fixes this for MacOS-X 10.3.3, by altering the > makefiles to understand the two ways of building a library/bundle and > having a variable setting 'BUNDLE=no' to day that the normal dynamic > library should be built rather than a bundle. The patch alters the > libecpg and libpq makefiles to set this variable, so these two are > built as normal dynamic libraries, while the other code continues to be > built as bundles. > > Probably there are other parts of the system which should not be > bundles either ... but I don't use them so I don't know. > Possibly behavior differs in older versions of MacOS-X ... again, I > don't have the old systems so I don't know. > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
This has been fixed by Tom. Thanks. --------------------------------------------------------------------------- Richard Frith-Macdonald wrote: > When trying to use postgresql on my MacOS-X system (10.3.3) I > encountered the problem that the libecpg and libpq dynamic libraries > could not be linked into my applications. > > Upon investigation, it turns out that the postgresql libraries on > MacOS-X/Darwin are being built as 'bundles' ... which means that you > can dynamically load them into a running program using the dlopen() > api, but you can't link them at application build time. This may be > correct behavior for some of the modules in postgres (eg the perl > module), but is certainly wrong for libecpg and libpq ... which are > meant to be linked with C (and other language) applications. > > I attach a patch which fixes this for MacOS-X 10.3.3, by altering the > makefiles to understand the two ways of building a library/bundle and > having a variable setting 'BUNDLE=no' to day that the normal dynamic > library should be built rather than a bundle. The patch alters the > libecpg and libpq makefiles to set this variable, so these two are > built as normal dynamic libraries, while the other code continues to be > built as bundles. > > Probably there are other parts of the system which should not be > bundles either ... but I don't use them so I don't know. > Possibly behavior differs in older versions of MacOS-X ... again, I > don't have the old systems so I don't know. > [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073