Dne 24. 11. 2015 15:44 napsal uživatel "Chapman Flack" <
c...@anastigmatix.net>:
>
> On 11/24/2015 05:33 AM, Kisung Kim wrote:
> > 2015-11-24 8:12 GMT+09:00 Chapman Flack <c...@anastigmatix.net>:
> >> On 11/23/15 15:14, Tom Lane wrote:
> >>> Lack of PGDLLIMPORT on the extern declaration, no doubt.
> >>
> > Actually, we encountered the situation before couple of months.
> > A client wanted to use orafce on Windows and the same build problem
> > occurred.
> > We performed a workaround to edit the PG source to export unresolved
> > symbols,
> > which I think of not a good solution.
>
> >> Has anyone got the stomach to try such a thing and see what happens?
> >> I don't have MSVC here.
> >
> > We have the environment to test your ideas.
> > Can you explain your ideas with more detail?
>
> Well, the main idea is just this: *IF* it is sufficient to declare
> a variable PGDLLIMPORT only in the code that is importing it (the
> big IF because I don't know whether that is true, but something I
> saw in that long earlier thread seemed to suggest it) ...
>
> Then ... the chief problem that needs to be solved is only that
> MSVC won't allow you to redeclare something with PGDLLIMPORT if
> it is also declared without PGDLLIMPORT in a .h file that you
> include. In other words, you can't simply:
>
> #include <pgtime.h>
> extern PGDLLIMPORT pg_tz session_timezone; /* the right way now */
>
> because it was already declared the wrong way in pgtime.h.
>
> So one idea is just this:
>
> #define session_timezone decoy_session_timezone;
> #include <pgtime.h>
> #undef decoy_session_timezone;
>
> extern PGDLLIMPORT pg_tz session_timezone; /* the right way now */
>
> which is not a multiple declaration of the same thing, because
> what got declared the wrong way in pgtime.h is now some other thing
> named decoy_session_timezone. You might need to supply a thing by
> that name, to avoid a linker complaint:
>
> pg_tz decoy_session_timezone; /* never used */
>
> IF the original premise is true, then this technique ought to be
> usable in most cases. It would, however, break in cases where the
> .h file declares macros or inline functions that refer to the
> symbol, because they would all end up referring to the decoy.
>
> My other idea, especially if there were several symbols needing
> to be treated this way, would be to do it all in one dedicated
> .c file, so any of the possible problems with #defining away parts
> of an .h file would be contained in one place, and that file could
> have a simple getter function:
>
> pg_tz getSessionTimezone() { return session_timezone; }
>
> which would be used in the rest of the code instead of referring
> to the global directly. (In that case, of course, the same getter
> function would have to be provided in the non-MSVC case too.)
> A setter function could also be made, if the code needs it.
>
I'll do these checks tomorrow.
Thank you very much, msvc is big unknown for me
regards
Pavel
