Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > If we make it /contrib/pg_upgrade_shlibs, will it need a documentation > > page? > > I don't see a need for that. Also, why would you make the directory > name different from the name of the shlib it's building --- or are > you having second thoughts about the present name?
Well, previously I needed separate shared objects because I didn't know what _new_ backend version I would be linking to and the symbols could be different. I actually dynamically linked in different SO's for different major versions. Now that it only targets the packaged version, I can do with a single shared object, but maybe it needs to be more generic, like pg_upgrade_tools.so or something like that. > > Can I built multiple shared libs in there if needed? > > No, but why would you need more than one? What you might need > (and can't have with the present hack) is more than one .o file > getting built into the shared library. Again, I used to need this, but I don't now. > > If we put > > it under /contrib/pg_upgrade, can it still be a separate build step? > > Would that work? > > Isn't that the same idea you just proposed? I realize we need a separate pgxs makefile for the executable and shared libraries. My question was whether the shared library directory should be under /contrib or under /contrib/pg_upgrade. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
