From: Kenneth J.Davis (firstname.lastname@example.org)
Date: Mon Apr 22 2002 - 00:39:32 EDT
"Mike Nordell" <email@example.com> 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
>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
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
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
The above statements are based on greping the source, so may not be entirely
accurate and do not reflect usage through get/set methods.
This archive was generated by hypermail 2.1.4 : Mon Apr 22 2002 - 00:37:40 EDT