@ManoloFLTK @michaelbaeuerle Just my 2 ct to the proposed patch:

1. OK in general, but since lround() is currently used only on macOS (Cocoa related stuff) and in src/Fl_Anim_GIF_Image.cxx we could as well make this locally in Fl_Anim_GIF_Image.cxx, particularly because the result of lround() is always cast to another type. It looks like we could use round() with a proper cast instead of lround() in the first place. @wcout What do you think (as the author of Fl_Anim_GIF_Image?).

2. The macOS usage doesn't need to be changed anyway because all supported versions provide lround().

3. The patch itself (if used as proposed) should probably be guarded by a POSIX version check to avoid multiple definitions if newer AIX versions provide lround() - maybe only to prevent using the own inline definition rather than the system provided one. @michaelbaeuerle ?

FYI: I tested a similar patch on Linux with and w/o the keyword inline. Using inline prevents a compilation warning on my Linux system (multiple definition of lround'otherwise). However, I'm not sure what happens iflround()has been defined by the includedmath.hheader and subsequently overridden by theinline` definition. I assume it would use the inline version and finally call round().

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <fltk/fltk/issues/942/2016510261@github.com>