-----Original Message-----
From: "Andrew Dunstan"<[EMAIL PROTECTED]>
Sent: 05/12/05 19:03:17
To: "Tom Lane"<[EMAIL PROTECTED]>
Cc: "Bruce Momjian"<pgman@candle.pha.pa.us>, "[EMAIL PROTECTED]"<[EMAIL
PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL
PROTECTED]>, "pgsql-hackers@postgresql.org"<pgsql-hackers@postgresql.org>
Subject: Re: [PATCHES] [HACKERS] snprintf() argument reordering not working
> I'm not sure I see the objection to stripping these out of the *.def files.
It will be a recipe for disaster if different builds of the same dll have
different exports - apps that pick up the wrong one from a shared dir for
example are likely to crash at startup. We went to some effort to prevent this
for 8.0, for example, by not having separate (and different) .def files for
each compiler, but by building them all from exports.txt.
Regards, Dave
-----Unmodified Original Message-----
Tom Lane wrote:
>Andrew Dunstan <[EMAIL PROTECTED]> writes:
>
>
>>The bad news: if we aren't compiling with NLS enabled, having those
>>entries in exports.txt makes the libpq build blow up. So either we need
>>to use pg_*printf unconditionally on Windows, or we need a little
>>Makefile + sed magic to strip those entries out of exports.txt when it
>>is used, if we're not doing NLS, or something of that kind.
>>
>>
>
>I think it's a bad idea for exports.txt not to be the same in all
>builds. So yeah, if we export these names at all then it has to be
>unconditional.
>
>What about Plan B? Per Bruce's comment, it should really only be ecpg
>that needs an extra copy of snprintf.o, and it's not like ecpg doesn't
>already pull in various port/ files for itself.
>
>
>
>
The problem is that the alias will be picked up by every libpq client. I
got around the problem with ecpg's libpgtypes by unaliasing sprintf and
snprintf. But we can't do that everywhere.
I'm not sure I see the objection to stripping these out of the *.def files.
I can't spend any more time on this now - I have spent far too much on
it already. My working patch is attached. Maybe I can look at it again
in a few days.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
