On 11/23/15 15:14, Tom Lane wrote: > Pavel Stehule <pavel.steh...@gmail.com> writes: >> I am trying to build Orafce and I have problem due access to exported >> variable session_timezone. >> Any idea what can be broken? > > Lack of PGDLLIMPORT on the extern declaration, no doubt. > > The fact that we've not heard this before implies that either nobody has > ever tried to use orafce on Windows, or it only very recently grew a > dependency on session_timezone.
Or something changed in the build process. I've had Ken Olson report the same symbol inaccessible when he builds PL/Java with MSVC, and he says it has happened since PG 9.4. I read myself to sleep about a week ago catching up on this old thread: http://www.postgresql.org/message-id/24290.1391303...@sss.pgh.pa.us What I (think I) took away from it was: 1. Un-PGDLLIMPORTed references to global *functions* work ok. Maybe they are thunked and a little less efficient, but they work. 2. Un-PGDLLIMPORTed references to global *variables*, not so much. They used to silently link (at least on some buildfarm critters) but hold bogus data (maybe a thunk, taken as data?). 3. The one concrete *action* taken in the course of that thread was to tweak the build process to make sure such cases at least *fail* because that's better than silent bogosity. So it's possible that (3) is what makes both Orafce and PL/Java seem to have started failing "recently" even though the code in question may be years old (and for most of that time, while linking without complaint, may have been bogus without someone noticing). The question that interests me most right now: how, if at all, can the extension author/maintainer work around this issue when it crops up? Obviously, the Right Thing To Do is report it and get the PGDLLIMPORT added here, but still for years to come the extension will have to cope with being built against PG distributions that lack it. (Never mind the reason, when the extension doesn't build, it's the extension that looks bad.) Now, I thought I spotted, somewhere in that long thread, the hint of an idea that the magic works as long as the *extension* has the variable declared PGDLLIMPORT, even if it wasn't declared that way when the PG executable itself was built. Anybody else remember that, or did I imagine it? The snag seemed to be, MSVC won't tolerate two extern declarations, one PGDLLIMPORT and one without, so you can't get away with including the .h file (which might not have the PGDLLIMPORT) and then declaring it yourself. You *might* get away with creating a separate C file (how about chamberofhorrors.c?) that, rather revoltingly, *doesn't* include the proper PostgreSQL .h files, only duplicates the necessary declarations with PGDLLIMPORT added, and exports some getter/setter methods to the rest of the extension code. (I like the idea of one chamberofhorrors better than scattering such rubbish all over the project.) That might work ok for log_min_messages and client_min_messages, which are just ints. Trickier maybe for session_timezone, which is a pg_tz, so you can't really avoid pgtime.h. That leaves even more revolting options, like #define session_timezone decoy_session_timezone #include <pgtime.h> #undef session_timezone extern PGDLLIMPORT pg_tz session_timezone pg_tz decoy_session_timezone; /* unused */ Has anyone got the stomach to try such a thing and see what happens? I don't have MSVC here. -Chap -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
