Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-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

In response to

pgsql-patches by date

Next:From: Tom LaneDate: 2004-08-17 03:21:12
Subject: Re: libpq build problem with <io.h> on MS VC++
Previous:From: Bruce MomjianDate: 2004-08-17 02:43:25
Subject: Re: libpq build problem with <io.h> on MS VC++

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-08-17 03:21:12
Subject: Re: libpq build problem with <io.h> on MS VC++
Previous:From: Bruce MomjianDate: 2004-08-17 02:43:25
Subject: Re: libpq build problem with <io.h> on MS VC++

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group