"Mike Nordell" <[EMAIL PROTECTED]> wrote on 4/21/2002 11:55:51 PM: > >Martin Sevior wrote: > >> Please folks, anyone with a clue (especially windows developers) look at >> Jeremey's build logs and find out how to fix the plugins. > >It seems that the plugins are accessing data that is not defined. F.ex. >GR_Graphics::s_iScreenResolution that is defined in AW "core". > >I can only think of three possible solutions: > >1) compile/link-in some private parts of AbiWord into that plugin (such as >the graphics class) to get the definition of the referenced symbols. This >would create different instances and possibly definitions of the same >data/functions. Bad. >2) Create virtual accessor functions for those symbols. >3) Export them from the .exe (simply not an option IMO). > >For a QnD fix it could probably be solved by linking with libAbiGr_s.lib. > .. >/Mike - please don't cc
1) is what I did to get AbiPaint to compile (as I am playing with it and want to test stuff -- yes I know its bad, but this problem is really annoying me). Another option, that may or may not produce usable plugins is the linker's /FORCE option, this is just as bad though. I don't believe any of these plugins are accessing these static variables directly. Unless I'm missing something the only direct references to s_iScreenResolution in the source is in gr_Graphics.h/cpp, though there is a symbol with the same name (and only referenced there as well) in gr_Win32Graphics.h/cpp s_szBuild_ID appears only referenced directly (for Win32 build) in: af/xap/xp/xap_App.h, af/xap/xp/xap_Prefs.cpp, text/fmt/xp/fp_Run.cpp, and wp/main/xp/abi_ver.cpp The above statements are based on greping the source, so may not be entirely accurate and do not reflect usage through get/set methods. Jeremy Davis [EMAIL PROTECTED]
