On Wed, Jun 14, 2006 at 06:23:36PM -0400, Bruce Momjian wrote:
> > is making the build step that strips not-officially-exported symbols
> > work on more platforms.
>
> Uh, well, I had some patches in the patch queue to go in that direction,
> but I thought the conclusion in that thread was that it
Bruce Momjian writes:
> Tom Lane wrote:
>> What would make sense to work on
>> is making the build step that strips not-officially-exported symbols
>> work on more platforms.
> Uh, well, I had some patches in the patch queue to go in that direction,
> but I thought the conclusion in that thread w
Tom Lane wrote:
> Bruce Momjian writes:
> > Thread added to TODO:
> > o Properly mark all libpq-exported functions with "PQ"
>
> Is that still relevant? I thought we'd done as much as we intended
> to do in that specific direction. What would make sense to work on
Oh, OK.
> is making
On Wed, Jun 14, 2006 at 05:54:56PM -0400, Bruce Momjian wrote:
>
> Thread added to TODO:
>
> o Properly mark all libpq-exported functions with "PQ"
I thought this was done already. At least, with a recent CVS I get
this:
$ nm -D libpq.so --defined-only |grep -v 'PQ\|pq\|lo_\|pg_'
000171
Bruce Momjian writes:
> Thread added to TODO:
> o Properly mark all libpq-exported functions with "PQ"
Is that still relevant? I thought we'd done as much as we intended
to do in that specific direction. What would make sense to work on
is making the build step that strips not-officiall
Thread added to TODO:
o Properly mark all libpq-exported functions with "PQ"
---
Tom Lane wrote:
> I find that libpq.so exports the following symbols that have neither
> PQ, pq, pg, nor lo_ as a prefix:
>
> Encryp
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Oct 16, 2005 at 06:21:37PM -0400, Tom Lane wr
Martijn van Oosterhout wrote:
> AIUI, we *do* limit the symbols for Windows (for libpq anyway, see
> exports.txt file) we just don't for UNIX since it can't be done
> portably. I posted a patch to -patches which does it for Linux and in
> principle any platform using GCC but there's no consensus on
On Thu, Oct 20, 2005 at 06:20:37PM +0800, William ZHANG wrote:
> I think it is a good idea to make the exported symbols clearer.
> We should only export the symbols needed. The
> output of "dlltool --export-all" is too big.
> AFAIK, we can generate *.def for Win32/MSVC++
> from a text file like th
I think it is a good idea to make the exported symbols clearer.
We should only export the symbols needed. The
output of "dlltool --export-all" is too big.
AFAIK, we can generate *.def for Win32/MSVC++
from a text file like this.
PQclear
PQfn
FooGlobalData DATA
"Neil Conway" <[EMAIL PR
On Mon, 2005-17-10 at 13:32 -0400, Tom Lane wrote:
> I dislike portability approaches that try to enumerate supported cases,
> rather than being general in the first place.
Do we need to have this on every platform we support? The symbols we
want to hide are internal by convention anyway -- using
On Mon, Oct 17, 2005 at 01:32:47PM -0400, Tom Lane wrote:
> (a) This problem is really not worth the trouble.
>
> (b) I dislike portability approaches that try to enumerate supported
> cases, rather than being general in the first place. Especially when
> we can be pretty certain that this area i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (I'm already desperately unhappy about the thin representation of
>> non-GNU toolchains in the build farm...)
> Me too. If you provide a list of the most important platforms/toolsets
> missing I will see if I can talk some people in
Martijn van Oosterhout writes:
> I can see a list of supported platforms [1], but not a list of
> supported compilers/linkers. If it's just a matter of reasearching the
> command-line options that can be done fairly easily, if anyone's
> interested...
(a) This problem is really not worth the trou
On Mon, Oct 17, 2005 at 12:20:06PM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > What other linkers do we need to support?
>
> All the non-GNU ones.
>
> (I'm already desperately unhappy about the thin representation of
> non-GNU toolchains in the build farm...)
Ok, so it's a matt
Tom Lane wrote:
Martijn van Oosterhout writes:
What other linkers do we need to support?
All the non-GNU ones.
(I'm already desperately unhappy about the thin representation of
non-GNU toolchains in the build farm...)
Me too. If you provide a list of the most important pl
Martijn van Oosterhout writes:
> What other linkers do we need to support?
All the non-GNU ones.
(I'm already desperately unhappy about the thin representation of
non-GNU toolchains in the build farm...)
regards, tom lane
---(end of broadcast)--
On Sun, Oct 16, 2005 at 06:21:37PM -0400, Tom Lane wrote:
> I find that libpq.so exports the following symbols that have neither
> PQ, pq, pg, nor lo_ as a prefix:
> It'd be nicer if we could filter out all exported symbols that don't
> appear in exports.txt, but I don't know any portable way to
I find that libpq.so exports the following symbols that have neither
PQ, pq, pg, nor lo_ as a prefix:
EncryptMD5
SockAddr_cidr_mask
fe_getauthname
fe_getauthsvc
fe_sendauth
fe_setauthsvc
freeaddrinfo_all
getaddrinfo_all
getnameinfo_all
md5_hash
rangeSockAddr
md5_hash seems a particularly unforgiv
19 matches
Mail list logo
