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 w
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
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 of "no-locale" switch
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 bui
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=loris&dt=2005-12-06%2011:57:20
Which raises another question: can we force the locale on Wind
t; Subject: Re: [PATCHES] [HACKERS] 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
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 e
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 n
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
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 broadcast)
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:
> ../../.
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
function
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
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 wo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> OK, eyeball this for the REL8_1_STABLE branch, please. It seems to work
> for me. No exports necessary.
OK, I see a few cleanups I want to make, but given the knowledge that
this patch does work on Win32, I should be able to get it done tonight.
Thanks
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
to
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 programs
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 a
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 b
IL PROTECTED]>, "[EMAIL PROTECTED]"<[EMAIL
PROTECTED]>, "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
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
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 dow
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 ent
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 rig
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,
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 th
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:
> 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 tra
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 ou
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
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 prin
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),
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 below
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 - wind
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, ple
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
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 wo
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 *print
Bruce Momjian 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 _fix_ was to disable
>
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 :( B
40 matches
Mail list logo
