Re: GUC variables invisible to contrib/ modules

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

In response to

Browse pgsql-hackers-win32 by date

  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++

Browse pgsql-patches by date

  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++