Re: problem with msvc linker - cannot build orafce
От | Pavel Stehule |
---|---|
Тема | Re: problem with msvc linker - cannot build orafce |
Дата | |
Msg-id | CAFj8pRBFsNg3AH_gCtbqAy_VGTTaPfW7ec8Thbm8HSq2h4cs3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: problem with msvc linker - cannot build orafce (Chapman Flack <chap@anastigmatix.net>) |
Список | pgsql-hackers |
<p dir="ltr"><br /> Dne 24. 11. 2015 15:44 napsal uživatel "Chapman Flack" <<a href="mailto:chap@anastigmatix.net">chap@anastigmatix.net</a>>:<br/> ><br /> > On 11/24/2015 05:33 AM, Kisung Kimwrote:<br /> > > 2015-11-24 8:12 GMT+09:00 Chapman Flack <<a href="mailto:chap@anastigmatix.net">chap@anastigmatix.net</a>>:<br/> > >> On 11/23/15 15:14, Tom Lane wrote:<br/> > >>> Lack of PGDLLIMPORT on the extern declaration, no doubt.<br /> > >><br /> > >Actually, we encountered the situation before couple of months.<br /> > > A client wanted to use orafce on Windowsand the same build problem<br /> > > occurred.<br /> > > We performed a workaround to edit the PG sourceto export unresolved<br /> > > symbols,<br /> > > which I think of not a good solution.<br /> ><br />> >> Has anyone got the stomach to try such a thing and see what happens?<br /> > >> I don't have MSVChere.<br /> > ><br /> > > We have the environment to test your ideas.<br /> > > Can you explain yourideas with more detail?<br /> ><br /> > Well, the main idea is just this: *IF* it is sufficient to declare<br/> > a variable PGDLLIMPORT only in the code that is importing it (the<br /> > big IF because I don't knowwhether that is true, but something I<br /> > saw in that long earlier thread seemed to suggest it) ...<br /> ><br/> > Then ... the chief problem that needs to be solved is only that<br /> > MSVC won't allow you to redeclaresomething with PGDLLIMPORT if<br /> > it is also declared without PGDLLIMPORT in a .h file that you<br /> >include. In other words, you can't simply:<br /> ><br /> > #include <pgtime.h><br /> > extern PGDLLIMPORTpg_tz session_timezone; /* the right way now */<br /> ><br /> > because it was already declared the wrongway in pgtime.h.<br /> ><br /> > So one idea is just this:<br /> ><br /> > #define session_timezone decoy_session_timezone;<br/> > #include <pgtime.h><br /> > #undef decoy_session_timezone;<br /> ><br /> >extern PGDLLIMPORT pg_tz session_timezone; /* the right way now */<br /> ><br /> > which is not a multiple declarationof the same thing, because<br /> > what got declared the wrong way in pgtime.h is now some other thing<br />> named decoy_session_timezone. You might need to supply a thing by<br /> > that name, to avoid a linker complaint:<br/> ><br /> > pg_tz decoy_session_timezone; /* never used */<br /> ><br /> > IF the original premiseis true, then this technique ought to be<br /> > usable in most cases. It would, however, break in cases wherethe<br /> > .h file declares macros or inline functions that refer to the<br /> > symbol, because they would allend up referring to the decoy.<br /> ><br /> > My other idea, especially if there were several symbols needing<br/> > to be treated this way, would be to do it all in one dedicated<br /> > .c file, so any of the possibleproblems with #defining away parts<br /> > of an .h file would be contained in one place, and that file could<br/> > have a simple getter function:<br /> ><br /> > pg_tz getSessionTimezone() { return session_timezone;}<br /> ><br /> > which would be used in the rest of the code instead of referring<br /> > to theglobal directly. (In that case, of course, the same getter<br /> > function would have to be provided in the non-MSVCcase too.)<br /> > A setter function could also be made, if the code needs it.<br /> ><p dir="ltr">I'll dothese checks tomorrow.<p dir="ltr">Thank you very much, msvc is big unknown for me<p dir="ltr">regards<p dir="ltr">Pavel
В списке pgsql-hackers по дате отправления: