|
|
On 3/15/24 14:31 Michael Bäuerle wrote:
'Albrecht Schlosser' via fltk.general wrote:
Did you try FLTK 1.4 (git) already?
On modern machines I use it on X11 (with Xft and Pango).
My old machines are still using 1.3 (X11 without Xft).
This should work on older machines as well. If not I'd like to hear
why not.
Maybe I can run some tests at the weekend.
That would be awesome, thanks in advance.
Currently I can test:
- Different CPU architectures including big endian systems like PowerPC
and SPARC (additionally needs aligned memory access)
As Matthias wrote already, big endian on whatever platform would be
very helpful because it seems that none of us devs has such a
system. I'd like to create one (I wrote that QEMU can run big endian
systems on a little endian host) but I didn't find the time yet to
setup such a system, and I'm not familiar with QEMU at all.
Virtualbox can't do that, and since I have only little endian
systems...
- Some old GCC versions back to the days of egcs (that can build FLTK 1.3)
Wow, that's really ancient!
- The Solaris machine with the SunPro compiler is currently defective
(maybe I can repair it for the test)
Probably not worth the effort. (?)
For me this was the main feature to choose FLTK and not Qt or something
else. I use it on decades old Workstations and it still works with
C90/C++98 compilers and X11 visuals with 8-Bit color.
I'm building FLTK with a modern g++ in C++98 mode from time to time to
check that it works. I'll also check this before the release. I'm not
sure if there are issues with C90 though, something like C++ comments in
C files (which I try to fix as well), but there may be other issues as
well although I hope FLTK builds fine with this compiler combo.
OK, I tried C90 mode but there were some incompatibilities I
couldn't fix. It looks like snprintf() and vsnprint() don't exist
(on Linux) in C90 mode, and our vsnprintf() "emulation" uses
snprintf() internally, or something like that. I could build FLTK
nevertheless, but with warnings.
C99 plus C++98 mode works well though after I fixed some issues.
I can take a look at the comments too.
I fixed some (new) C++ comments in C headers or such headers that
are included indirectly by C code, this seems to be fine now. There
are still some warnings, but these are benign. Anyway, if you can
find real *errors* I'd like to fix them.
[...] the "L" in FLTK was always true.
The "F" is another story. I never reached the performance of Motif with
FLTK. But it was good enough even for machines with <100 MHz CPU clock.
Nowadays, with always faster CPU's any difference should IMHO become
less important. Which doesn't mean that FLTK development would
neglect the "F" aspect...
And the ten year old STR #2961 is still present on NetBSD (approx. one
second lag when moving the mouse from one menu bar item to the next,
tested again with multi-GHz CPUs). I still avoid Unicode locales on
NetBSD to make FLTK happy (no problems with ISO-8859-1).
Yes, unfortunately that's true. I could never find time to dig into
the details which is necessary to understand what's going on and how
to fix it best. As far as I remember your given patch was also only
a kind of workaround. Maybe we can take this on our roadmap for
1.5.0 - unless someone finds a real fix.
The documentation of CMake says that C++11 is required to build it.
According to <https://gcc.gnu.org/projects/cxx-status.html>:
|
| GCC 4.8.1 was the first feature-complete implementation of the 2011
| C++ standard, [...]
It would be consistent when FLTK 1.5 would use at least that standard.
Yep, C++11 would be the minimum we considered for the time being.
GCC 4.8 requires a C++98 compiler for bootstrap and most machines from
the current century should be able to compile it.
I wouldn't want to take care of compiler bootstrapping. That's far
beyond the scope of library development. As far as I'm concerned,
users "living in the last century" are on their own and may use FLTK
1.3 anyway or migrate to 1.4 which should have the same
prerequisites.
C++17 would require GCC 11, that itself requires C++11 for bootstrap.
GCC 9 may be sufficient for partial support in theory, but maybe not
in reality. Both versions likely do not compile on old machines at all,
or would require an amount of memory that such machines cannot provide.
See above, for such old machines FLTK 1.4.x would be the final
release(s).
This means that the choice of C++11 vs. C++17 for FLTK 1.5 makes a big
difference for the number of supported systems.
This has not yet been decided, but as I said we should IMHO be
conservative in this decision. If there's no compelling reason to
use C++17 we can probably keep C++11 for, let's say, the next 5 or
10 years or so. This will be discussed later.
Would cross-compiling be an alternative for your old systems?
I don't know how cross-compiling should work e.g. for AIX or HP-UX,
where GCC uses native binutils and libraries work different than on
ELF-based systems.
I don't know either, that's why I asked.
I would expect that namespaces and STL are not the problem, they exist
since C++98. 'auto' would require at least C++11.
Yep, that's why I believe that C++11 would be a good compromise.
Note: Non-mainstream systems move slower than most people think.
Example for NetBSD 9 (version 10 not released yet):
|
| $ gcc --version
| gcc (nb4 20200810) 7.5.0
Hmm, 2020 doesn't sound too old but I understand what you mean.
With some options modern compilers should be able to create warnings,
if unwanted language features are used.
As I wrote before I can compile with gcc/g++ in C99 and C++98
standard (w/o GNU extensions) and I found warnings when we used
newer features in the past. Which doesn't mean that there can be old
compilers that are pickier or don't implement the full standard (or
that gcc's diagnostics are maybe incomplete).
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/0c341420-c547-4be9-a24b-e0a9a071e9dc%40aljus.de.
[ Direct Link to Message ] | |
|
| |