pawel wrote:
> 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:
checking sys/stdtypes.h usability... no
checking sys/stdtypes.h presence... no
checking for sys/stdtypes.h... no
[..]
checking for strlcat... no
checking for strlcpy... no
..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.
> checking for pthread_create using -lpthreads... no
> checking for X overlay visuals... no
Yep, same here:
checking for pthread_create using -lpthreads... no
checking for pthread_create using -lpthread... yes
[..]
checking for X overlay visuals... no
> 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. Maybe try logging in as root, eg:
su - root
(as opposed to 'su root' or just 'su'), and assuming root has
a "default" environment, compile with that, just to rule out
env variables as being a possible issue.
> A few of these liberally sprinkled about:
> ..warning: suggest parentheses around ‘&&’ within ‘||’
Sounds like maybe a newer compiler that's doing extra checks.
In my case:
# g++ --version
g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
^^^^^
>
> and then:
> Compiling Fl_Text_Buffer.cxx...
> Fl_Text_Buffer.cxx: In member function ‘int Fl_Text_Buffer::undo(int*)’:
> Fl_Text_Buffer.cxx:344: warning: suggest parentheses around ‘&&’ within
> ‘||’
> Fl_Text_Buffer.cxx: In function ‘char chooseNullSubsChar(char*)’:
> Fl_Text_Buffer.cxx:1346: warning: array subscript has type ‘char’
>
> 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.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
