On Tue, May 09, 2006 at 09:18:17AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Eh? It stops a program expecting libpq4 being linked to libpq3 for any
> > reason, so the above situation can't happen. You don't need to version
> > any structs, only the functions using them.
>
> If w
Martijn van Oosterhout writes:
> Eh? It stops a program expecting libpq4 being linked to libpq3 for any
> reason, so the above situation can't happen. You don't need to version
> any structs, only the functions using them.
If we have an existing app built against an unversioned libpq, what
happen
On Tue, May 09, 2006 at 01:50:38PM +0200, Peter Eisentraut wrote:
> Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout:
> > Depends what you mean by signature. The structures of PGconn and
> > PGresult have changed over time, so if you you pass a PGresult
> > allocated by libpq4 to a fun
Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout:
> Depends what you mean by signature. The structures of PGconn and
> PGresult have changed over time, so if you you pass a PGresult
> allocated by libpq4 to a function in libpq3, it'll crash.
Symbol versioning only affects functions (a
On Tue, May 09, 2006 at 10:19:56AM +0200, Peter Eisentraut wrote:
> Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
> > What it does is remove the restriction that any one program can only
> > use (directly or indirectly) one version of libpq at any moment.
> > Programs can use ind
Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
> What it does is remove the restriction that any one program can only
> use (directly or indirectly) one version of libpq at any moment.
> Programs can use indirectly postgres via PAM or NSS or other such
> pluggable interfaces. Curr
On Sat, Apr 29, 2006 at 03:07:30PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Now that 95% of this patch [1] (currently in the hold queue) has been
> > implemented, perhaps we should go the final 5% and version the symbols
> > to fix the ambiguous symbol problem forever (on linux
Martijn van Oosterhout writes:
> Now that 95% of this patch [1] (currently in the hold queue) has been
> implemented, perhaps we should go the final 5% and version the symbols
> to fix the ambiguous symbol problem forever (on linux at least, though
> anywhere with the GCC toolchain will work).
I
Tom Lane wrote:
> I just came across some documentation claiming that it's possible to do
> similar exported-symbol filtering in Linux:
> http://people.redhat.com/%7edrepper/dsohowto.pdf
> I'm going to see if I can make that work along the same lines as my
> Darwin patch. If we can get it
Bruce Momjian writes:
> The problem is that the call to thread.c::pqGetpwuid() happens in a
> #ifndef WIN32 block, so the function is not seen by Win32, so we don't
> get a compile error.
> I am thinking your patch is a good idea because it will give us a
> non-Win32 platform that has the _check_
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking your patch is a good idea because it will give us a
> > non-Win32 platform that has the _check_ behavior. We do have to bump
> > the major for ecpg libs for this, but not libpq.
>
> No, because if 8.2 ships with a libpq.so.4 that doesn't
Bruce Momjian writes:
> I am thinking your patch is a good idea because it will give us a
> non-Win32 platform that has the _check_ behavior. We do have to bump
> the major for ecpg libs for this, but not libpq.
No, because if 8.2 ships with a libpq.so.4 that doesn't expose
pqGetpwuid, it will
We have two approaches for dealing with pgport leakage. For libraries,
we remove libpgport from the link line and recompile our own object
files:
# Need to recompile any libpgport object files
LIBS := $(filter-out -lpgport, $(LIBS))
OBJS= execute.o typename.o descriptor.
Recent versions of Darwin spew a lot of multiply-defined-symbol warnings
while building Postgres, mostly because the programs in src/bin import
both libpq and libpgport, and libpq includes copies of many of the
libpgport files. Since the libpgport routines aren't officially part of
the libpq API,
14 matches
Mail list logo
