On 25.03.2012 22:46, Ian MacArthur wrote:
>
> On 25 Mar 2012, at 06:50, David FLEURY wrote:
>>
>> Hum, the code is from Fl_win32.cxx, the function is :
>> Fl_X* Fl_X::make(Fl_Window* w) and try to access a protected enum.
>>
>> Under VS, I don't see any link between Fl_X and Fl_Widget.
>>
>> The filename is Fl_win32.cxx this is probably why it not complains under
>> Linux. It's not compiling at all.
>
>
> Yeah, I get that; except that my mingw build seemed to be OK. I guess that
> maybe the gcc-derived mingw handles the visibility of enums differently or
> something? FWIW, the mingw I have is from gcc 3.4.something, so not the
> latest deal (I think mingw current is 4.5 or so...)
I have MinGW gcc 4.6.1, and it builds w/o errors as well, and I
think that there is WIP on gcc 4.7.x, or that it is already
available.
I also believe that we already had a similar problem. This one can
be fixed easily with "friend class Fl_X;" in Fl_Widget.H, like this
patch:
Index: FL/Fl_Widget.H
===================================================================
--- FL/Fl_Widget.H (revision 9300)
+++ FL/Fl_Widget.H (working copy)
@@ -99,6 +99,7 @@
*/
class FL_EXPORT Fl_Widget {
friend class Fl_Group;
+ friend class Fl_X;
Fl_Group* parent_;
Fl_Callback* callback_;
... instead of making the enum public. I'm not sure which one is
better though, but I'd tend to use the friend statement in this
case. Anybody?
>>>> Second (a lot of)
>>>> FL/Fl_Window.H(55): error C2487: 'no_fullscreen_y' : member of dll
>>>> interface class may not be declared with dll interface
>>>> FL/Fl_Window.H(55): error C2487: 'no_fullscreen_w' : member of dll
>>>> interface class may not be declared with dll interface
>>>> FL/Fl_Window.H(55): error C2487: 'no_fullscreen_h' : member of dll
>>>> interface class may not be declared with dll interface
>>>>
>>>> I think VS applies 'static' attribute only to first variable from list
>>>> ('no_fullscreen_x').
>>>
>>> Ah, that really is odd - that just outright looks like a compiler bug to
>>> me, then.
>>>
>>> Or am I missing something here too?
>>
>> Same for me. Too early to find another reason. I will check later.
>
>
> Just for the record, in case anyone got the wrong idea from my posts, I'm not
> opposed to the patch in any way; it all seems quite reasonable changes (i.e.
> the Fl_Window.H change is effectively NULL, and I don't *think* there's any
> harm in the Fl_Widget.H change, though I'm not sure about that...)
> It's just that it all seemed a little odd...
First, I'm not sure at all that adding static class members keep
the ABI intact, as Manolo states in the comments to the offending
code. This should probably be in fltk.development, but anyway...
Manolo, did you really intend to add static class members as opposed
to static external variables in the ABI compatible case? ...
Second, I tried a few different changes, and I got slightly different
error messages with VC2008 Express and VC2010 Express, resp.. I also
tried to move the offending variables outside the class, adding
extern and/or FL_EXPORT, but I'm not sure what to do here. We should
wait for Manolo to chime in...
@Manolo: If you could check the ABI issues and tell us what you really
intended (just to be sure I'm not missing a point), then I could test
maybe another patch with VC2008 and VC2010 Express...
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
