This'll depend on what headers you have installed for glibc I guess, but
I doubt we can get rid of all the declared with attribute
warn_unused_result warnings unless we either alter the code, or maybe
there's some compiler option to tell gcc to just shut up about them?
Most of them are just
This'll depend on what headers you have installed for glibc I guess, but
I doubt we can get rid of all the declared with attribute
warn_unused_result warnings unless we either alter the code, or maybe
there's some compiler option to tell gcc to just shut up about them?
Most of them are just
-Wno-unused-result is the GCC option you are looking for...
On Jan 18, 2011, at 3:03 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote:
This'll depend on what headers you have installed for glibc I guess, but
I doubt we can get rid of all the declared with attribute
warn_unused_result warnings
On 14.01.2011, at 18:38, Michael Sweet wrote:
I can certainly make fltk.bugs/fltk-bugs read-only. It'll mean some changes in
the bug system too (emails to fltk-bugs would need to be posted to fltk.bugs
directly, for example) but nothing we can't handle.
Mike, we've got at least three positive
On 18.01.2011, at 19:14, Albrecht Schlosser wrote:
On 14.01.2011, at 18:38, Michael Sweet wrote:
I can certainly make fltk.bugs/fltk-bugs read-only. It'll mean some changes
in
the bug system too (emails to fltk-bugs would need to be posted to fltk.bugs
directly, for example) but nothing
On Jan 18, 2011, at 10:14 AM, Albrecht Schlosser wrote:
On 14.01.2011, at 18:38, Michael Sweet wrote:
I can certainly make fltk.bugs/fltk-bugs read-only. It'll mean some changes
in
the bug system too (emails to fltk-bugs would need to be posted to fltk.bugs
directly, for example) but
Yuri P. Fedorchenko wrote:
I want to tell that not all warning are needed to suppress.
I think that for examle commit [Library] r8275 - branches/branch-1.3/FL
seams
strange for me
one of changes.
- virtual const char *item_text(void *item) const { return 0L; }
+ virtual const char
With the latest svn update there is a problem with this new macro
FL_INTERNALS I think.
When compiling fluid there is a problem:
Compiling CodeEditor.cxx...
In file included from ../FL/fl_draw.H:39:0,
from ../FL/Fl_Text_Display.H:36,
from
