> > Can somebody with a failing F11 (or similar) system compile
> and run the
> > following code and let us know what the output is, please?
> >
> > ----------------
>
> [pa...@pawelsbox Release]$ ./glib
> __GLIBC__ defined as: 2L
> __GLIBC_MINOR__ defined as: 10L
>
>
> how's that for quick service!
Pah! Quick? I had to write that whole "complex" test program...
OK, so now we know that (as expected) it is glibc-2.10 that introduces
the "problem", and we can detect that at compile time, so a work around
is feasible.
That's a start...
> Replacing line 93 with 82 in filename_list.cxx, and then make.
And I assume that filename_list.cxx then compiled succesfully for you?
> Compiling fl_set_fonts.cxx...
> In file included from fl_set_fonts.cxx:39:
> fl_set_fonts_xft.cxx: In static member function 'static
> Fl_Font Fl::set_fonts(const char*)':
> fl_set_fonts_xft.cxx:274: error: invalid conversion from
> 'const char*' to 'char*'
> fl_set_fonts_xft.cxx:275: error: invalid conversion from
> 'const char*' to 'char*'
> fl_set_fonts_xft.cxx:280: error: invalid conversion from
> 'const char*' to 'char*'
> make[1]: *** [fl_set_fonts.o] Error 1
> make: *** [all] Error 1
Argh. <swear-word here>
OK, this is a different manifestation of the same problem. In this case,
they (the glibc folk) have taken advantage of C++'s ability to overload
functions to have multiple functions with the same name but differing
signatures.
In this specific case, what they have done (and to be fair the reasoning
is sound, just annoying in practice...) is defined two different
versions of strchr() and related functions.
So, for example now there are (I think these types are correct):
const char * strchr(const char *, int);
char * strchr(char *, int);
Where the idea is that *if* the function is passed a const char *, then
it must return a const char *, whilst if it is passed a (non-const) char
* then it can return a "plain" char *.
The "old" definition of strchr took a const char * input but returned a
char * that was actually pointing to the const char string... So
potentially removing the const-ness of the passed parameter, which is a
Bad Thing...
At compile time, the compiler now picks whichever version of strchr()
matches the const-ness of the input string, but that means that our code
in fl_set_fonts_xft.cxx is now wrong.
What a pain...
The quick hack is to find the three lines identified in the error (274,
275, 280) and tweak them all as follows (they are each different, but
all of this form) -
Before:
stop = strchr((const char *)font, ',');
After:
stop = strchr((char *)font, ',');
Etc.
That ought to work for the gcc-4.4/glibc 2.10 case, but will cause
warnings (although probably NOT errors) for most other build platforms.
The long version would look like:
#if (__GLIBC__ >= 2) && (__GLIBC_MINOR__ >= 10)
stop = strchr((char *)font, ',');
#else
stop = strchr((const char *)font, ',');
#endif
In each case (although I have not actually tried to compile that
code...)
Something like this latter example is probably the Right Thing to do to
address this problem in the general sense.
Let us know how you get on - if you can confirm this works, we can
probably try to push a more complete fix ASAP.
Note that it is possible there are other gotchas in the code due to this
glibc change, but a version of this workaround ought to be possible for
all of them, I guess.
--
Ian
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
