From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
Cc: | pgsql-hackers-win32(at)postgresql(dot)org, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: GUC variables invisible to contrib/ modules |
Date: | 2004-08-17 02:51:09 |
Message-ID: | 200408170251.i7H2p9e04597@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 pgsql-patches |
Yep, DLLIMPORT is the right fix. Patch attached and applied.
---------------------------------------------------------------------------
Mark Cave-Ayland wrote:
> Hi everyone,
>
> I've been experimenting with compiling PostGIS (a contrib module) under
> Win32 and I've noticed a difference in accessing GUC variables between
> Linux and Win32 using PostgreSQL 8.0 beta 1. In part of the PostGIS
> statistics routines we have a check like this:
>
>
> #include "commands/vacuum.h"
> ...
>
> /* If the attstattarget column is negative, use the default
> value */
> /* NB: it is okay to scribble on stats->attr since it's a copy
> */
> if (attr->attstattarget < 0)
> attr->attstattarget = default_statistics_target;
>
>
> Under Linux, PostGIS compiles and links fine without any trouble.
> However, when compiling under Win32 we get the following message:
>
> Info: resolving _default_statistics_target by linking to
> __imp__default_statistics_target (auto-import)
> fu000024.o(.idata$3+0xc): undefined reference to `libpostgres_a_iname'
> nmth000023.o(.idata$4+0x0): undefined reference to
> `_nm__default_statistics_target'
> c:\mingw\bin\dllwrap.exe: c:\mingw\bin\gcc exited with status 1
>
>
> The current "fix" to enable this to work correctly is to change the
> relevant line in /src/include/commands/vacuum.h from "extern int
> default_statistics_target;" to "extern DLLIMPORT int
> default_statistics_target;". However, I'm not convinced this is the
> correct fix given that other contrib modules may require access to other
> GUC variables.
>
> I've looked at guc.c and found GetConfigOption() which I think may be a
> better option since I don't think accessing the variable directly will
> work when using custom variables. Would this be the "correct" way to
> access GUC variable values from within other modules that would work
> correctly under both Win32 and UNIX-type OSs?
>
>
> Cheers,
>
> Mark.
>
> ---
>
> Mark Cave-Ayland
> Webbased Ltd.
> Tamar Science Park
> Derriford
> Plymouth
> PL6 8BX
> England
>
> Tel: +44 (0)1752 764445
> Fax: +44 (0)1752 764446
>
>
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender. You
> should not copy it or use it for any purpose nor disclose or distribute
> its contents to any other person.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 721 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-17 03:21:12 | Re: libpq build problem with <io.h> on MS VC++ |
Previous Message | Bruce Momjian | 2004-08-17 02:43:25 | Re: libpq build problem with <io.h> on MS VC++ |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-08-17 03:21:12 | Re: libpq build problem with <io.h> on MS VC++ |
Previous Message | Bruce Momjian | 2004-08-17 02:43:25 | Re: libpq build problem with <io.h> on MS VC++ |