I might be wrong, but I know this sort of thing has come up
many times before.
I thought the way this works is configure somehow figures this
stuff out, and defines macros that we then test for.
This way we don't have to hard code glib versions, configure
reaches out into the #include files, finds the prototypes, and
defines macros accordingly.
I don't know how this stuff works, I know zippo about configure,
but I assume when configure runs, and it does all those checks
for the existence of certain OS specific functions and prototypes,
that the same thing would be done here.
Certainly signal()'s prototype has changed over the years,
and other OS functions like it. And I'm pretty sure we never
looked at compiler version numbers to solve these things.
Who are our configure experts? I know Mike is the master on
this stuff, but if he's been busy, maybe we have some other
configure gurus who haven't weighed in.. or maybe they have,
and looking at glib macros IS the right way? I dunno myself..
> I can confirm that glibc 2.9 doesn't have this problem. Please see the
> following from ubuntu 9.04:
>
> $ uname -a
> Linux ubuntu-vm 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC
> 2009 i686 GNU/Linux
>
> $ gcc --version
> gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
> ...
>
> $ g++ --version
> g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
