> > Running ./configure shows no errors as such but I get some > negatives: > > > > checking sys/stdtypes.h usability... no > > checking sys/stdtypes.h presence... no > > checking for sys/stdtypes.h... no > > FWIW I get those too on my ubuntu 8.x system with 1.3.x current:
Yes - I think that is normal. I'm pretty sure this is a check for older systems that used to put the types in "odd" places... > ..and the png errors should be ok; that just means FLTK will > fail over to using its own PNG library when it can't find the OS > ones, which I prefer to use anyway, as I know FLTK > keeps sync with > itself. Although, for my money, I tend to prefer the system PNG over the flkt built-in PNG. YMMV, of course... I'd assume the OP does have libpng on his machine but simply does not have the dev header packages installed. Ditto for libz and libjpeg I suppose... > > > When I then make, I get this: > > Fl.cxx: In static member function ‘static int > Fl::handle(int, Fl_Window*)’: > > Fl.cxx:959: warning: suggest parentheses around ‘&&’ > within ‘||’ > > Although putting parens in that line couldn't hurt, > I don't get that error here. I would think the rules of > precedence would define correct behavior in that case. > Maybe your compiler is newer, or maybe you have a compiler > specific environment variable set that enables more checks > than usual. I'm fairly sure this is just gcc-4.3.x being more fussy than its predecessors. The kicker is that this will become more widespread, so we probably do need to either turn off this warning or tweak the code to "fix" it. Not that it is actually broken. In a wider sense, there seems to be a move towards making some things we have always done (e.g. handling of string constants and so forth) that are deprecated now and throw a pile of warnings with gcc-4.3.x that we never used to get. Some of these are mooted to become errors in some future iteration of gcc... Urgh. We maybe need to fix that too. > > and lastly: > > Compiling filename_list.cxx... > > filename_list.cxx: In function ‘int > fl_filename_list(const char*, dirent***, int (*)(dirent**, > dirent**))’: > > filename_list.cxx:93: error: invalid conversion from ‘int > (*)(const void*, const void*)’ to ‘int (*)(const > dirent**, const dirent**)’ > > filename_list.cxx:93: error: initializing argument 4 of > ‘int scandir(const char*, dirent***, int (*)(const > dirent*), int (*)(const dirent**, const dirent**))’ > > Hmm, sounds like they've changed the types of the system calls. > > They've been doing that a lot in the last 10 years, > changing system > calls that used to take typeless 'const void*' to more > reasonable > data types like 'const dirent*'. > > Sounds like we need to fix that in FLTK with some casts. Yup. This is STR #2205, as Albrecht pointed out. #2205 is actually against fltk-2 IIRC, but clearly the problem is in all our code. The kicker is that this is a change in glibc, so we need to detect the glibc version in use at configure/build time and change the types accordingly. However, the code in question (filename_list.cxx) already has several different "choices" for the scandir signature coded in with ifdefs, so that part of the problem is already solved, we just need to pick the right option... 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
