2005/12/4, Andrew Dunstan [EMAIL PROTECTED]:
Tom said:
Would it work to modify c.h so that it #include's libintl.h, then #undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive
2005/12/6, Nicolai Tufar [EMAIL PROTECTED]:
IIRC last time I tried this it didn't work too well ;-( I will have
another go. I think it's the best way to go.
Very well, I will try to put up a patch to implement it in a couple of days.
Oh boy, it is already fixed. Sorry folks, my error.
] snprintf() argument
reordering not working
We hope to put out a new pginstaller in the next few days
for testing to make sure this has been resolve before releasing 8.1.1.
http://developer.postgresql.org/~dpage/postgresql-8.1t1.zip
DO NOT use in production as it got virtually no testing. I
Tom Lane wrote:
Please test ...
Well, if you look here you'll see a bunch of Turkish messages, because I
forgot to change the locale back ;-)
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=lorisdt=2005-12-06%2011:57:20
Which raises another question: can we force the locale on
Andrew Dunstan [EMAIL PROTECTED] writes:
Which raises another question: can we force the locale on Windows, or
are we stuck with the locale that the machine is set to? But maybe that
belongs in another thread.
I thought we'd put in some sort of no-locale switch specifically for
the buildfarm
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Which raises another question: can we force the locale on Windows,
or are we stuck with the locale that the machine is set to? But
maybe that belongs in another thread.
I thought we'd put in some sort
Andrew Dunstan wrote:
I committed the pg_regress change back in Nov but didn't change
buildfarm to use it. And now I look at it more closely I think it
won't work. We have:
/ # locale
/ NOLOCALE :=
ifdef NO_LOCALE
NOLOCALE += --no-locale
endif
I think instead of the += line
I wrote:
Bruce Momjian said:
OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the
Andrew Dunstan [EMAIL PROTECTED] writes:
However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using our
previous, very-broken
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, a very simple test shows that the libintl printf does indeed do
%m$ processing:
...
So the next question is why isn't it working in the build.
Is it possible that the build that was being complained of was using our
Andrew Dunstan [EMAIL PROTECTED] writes:
What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: $s veritaban?n
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
What is more, when I set the locale of my machine to Turkish and run the
installer project's 8.1_RC1 which I happen to have installed there, and
set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
LOG: $s
Andrew Dunstan [EMAIL PROTECTED] writes:
With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took).
Ah. OK, that makes sense.
But the
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took).
Ah. OK, that
Bruce Momjian wrote:
Was the last patch you sent in ready for application, or are you still
fooling with it?
He is still working on it. It did not handle all *printf functions, as
he mentioned, and he might have other changes.
Yeah.
The good news: the new pg_*printf does the
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
Andrew Dunstan [EMAIL PROTECTED] writes:
With luck I can probably wrap this up today for the 8.1 stable branch -
it would be nice if the new release actually did NLS right.
BTW, core has already agreed to postpone the releases a couple days
while we make sure we have this problem nailed down.
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
@postgresql.orgpgsql-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
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
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
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
The problem is that the alias will be picked up by every libpq client.
Not at all; libpq clients do not import c.h.
Well, all the programs that use postgres-fe.h do.
Sure, but all of them do
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to use it
unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
to our client-side
Andrew Dunstan wrote:
Tom Lane wrote:
I'm coming around to thinking that the simple solution is just to
use it unconditionally on Windows.
I agree that that's what we should do, but it should be done the same
way we handle other routines from libpgport. None of those are exported
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
work for me. No exports necessary.
er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD and 8.1 branches.
It appears to work in
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
OK, eyeball this for the REL8_1_STABLE branch, please. It seems to
work for me. No exports necessary.
er try this instead. I missed a line from configure.in
I cleaned this up slightly and committed it into HEAD
I did some research and can report what was happening with *printf and
libintl.
Basically, there are two versions of libintl. Versions before 0.13
(November 2003) use the libc version of *printf to handle printing of
translation strings. Version 0.13 and after provide their own *printf
Andrew Dunstan [EMAIL PROTECTED] writes:
Also, we need a way to stop this from happening all over the build:
In file included from ../../../../../../src/include/c.h:820,
from ../../../../../../src/include/postgres.h:48,
from utf8_and_sjis.c:14:
Tom Lane wrote:
Not sure why my build didn't show the problem in pgtypeslib, though.
That should have failed with or without libintl macros.
On *nix it probably just thinks it's an external symbol to be resolved
later.
cheers
andrew
---(end of
Andrew Dunstan [EMAIL PROTECTED] writes:
If we don't do this then we need to link snprintf into libpgtypes just
like we do for ecpg, but it seems like overkill.
It might be overkill today, but what about tomorrow when someone decides
to internationalize libpgtypes? I made it link in there
Bruce Momjian wrote:
OK, here is what happened. In March 2005, we got reports of compile
problems on Win32 using NLS:
http://archives.postgresql.org/pgsql-hackers/2005-03/msg00710.php
(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces
Andrew Dunstan wrote:
Tom said:
Would it work to modify c.h so that it #include's libintl.h, then
#undefs
these macros, then #includes port.h to define 'em the way we want?
Some or all of this might need to be #ifdef WIN32, but that seems like
a reasonably noninvasive solution if it can
Andrew Dunstan [EMAIL PROTECTED] writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please advise.
Plan A would be to
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that - windows
experts, please
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
That got me through the backend compile and through libpq to ecpg, which
fell over at the link stage complaining about missing references to
pg_sprintf and pg_snprintf ... not sure how to fix that -
OK, a few things. First, Tom has fixed snprintf.c so it should properly
process positional parameters now. Would you first test the libintl
version of *printf to see if it can process %$ parameters (probably by
hacking up any language file and testing the printing), and then try
your patch
Bruce Momjian said:
OK, a few things. First, Tom has fixed snprintf.c so it should
properly process positional parameters now. Would you first test the
libintl version of *printf to see if it can process %$ parameters
(probably by hacking up any language file and testing the printing),
and
Nicolai Tufar wrote:
Greetings,
I thought it will be as simple as changing Makefile, the issue seem to be
much more complicated. Unfortunately I have no PostgreSQL building
environment handy and will not be able to look at it until the end of next
week because I am moving my house :( But
Bruce Momjian pgman@candle.pha.pa.us writes:
(See the quoted text under the posted text as well.) Basically,
libintl.h on Win32 replaces *printf calls with its own versions, and
does it using macros, _just_ like we do. This of course causes
conflicts and the system fails to compile. The
38 matches
Mail list logo
