CentOS 6 - FLTK Problems
79 views
Skip to first unread message
Glover George
Jul 31, 2016, 12:48:52 AM7/31/16
to OpenVSP
Hi all,
After figuring out VSP_NO_GRAPHICS on CentOS/RHEL with the git repo as of today, I have been trying to build it with graphics. It appears that the FLTK requirement has continued to follow the bleeding edge of FLTK, and seems to have left us CentOS 6 users behind. Fix after fix, there seem to just be too many issues with fltk/CentOS requirements. First it was fltk and libXfixes. Ignoring that, there are now more issues with undefined references due to Xft versions, and many more.
I guess my question is two part.
1. When did the fltk requirement for using nightly snapshots occur? If I just want to build with fltk-1.3.3 stable, how far do I have to go back in the git repo?
2. Is continuing reliance on latest release of dependencies due to habit, or for functional reasons? I ask this, not in a condescending way, I promise. OpenVSP is increasingly useful in a government setting. Approved software (due to software assurance, STIGS, etc) will continue to require that users can't upgrade to the latest Ubuntu/Fedora flavor of Linux.
With that being said, I think the best course of action for us would be to pull older source code for older distros, but what is the right method for this? Does the git repo have branches that track releases?
Cheers.
After figuring out VSP_NO_GRAPHICS on CentOS/RHEL with the git repo as of today, I have been trying to build it with graphics. It appears that the FLTK requirement has continued to follow the bleeding edge of FLTK, and seems to have left us CentOS 6 users behind. Fix after fix, there seem to just be too many issues with fltk/CentOS requirements. First it was fltk and libXfixes. Ignoring that, there are now more issues with undefined references due to Xft versions, and many more.
I guess my question is two part.
1. When did the fltk requirement for using nightly snapshots occur? If I just want to build with fltk-1.3.3 stable, how far do I have to go back in the git repo?
2. Is continuing reliance on latest release of dependencies due to habit, or for functional reasons? I ask this, not in a condescending way, I promise. OpenVSP is increasingly useful in a government setting. Approved software (due to software assurance, STIGS, etc) will continue to require that users can't upgrade to the latest Ubuntu/Fedora flavor of Linux.
With that being said, I think the best course of action for us would be to pull older source code for older distros, but what is the right method for this? Does the git repo have branches that track releases?
Cheers.
Rob McDonald
Jul 31, 2016, 1:33:46 AM7/31/16
to ope...@googlegroups.com
Glover,
I'm sorry you've had all this frustration.
On Linux, my assumption is that you don't build your own FLTK (and
most other libraries from the Libraries sub-project), instead, you
build against the system installed one. You tell the OpenVSP build
system this with VSP_USE_SYSTEM_FLTK=true and the like.
FLTK claims/strives to maintain compatibility with old versions -- it
has been a while since I have done this, but I've compiled OpenVSP
against some very old versions of FLTK in the past (1.1.10 ish I
think). I only recall one small API incompatibility to that version.
OpenVSP has gone to a custom-selected bleeding edge FLTK versions in
order to satisfy build problems on all the platforms we try to support
(not for some particular functionality in OpenVSP). The only somewhat
recent FLTK feature we knowingly support is retina display support on
OSX, but that should be conditionally compiled to protect for old
versions.
FLTK development is active, but they are slow to release new versions.
1.3.3 is well over a year old, tons has happened since then. 1.3.4 is
promised as a stable version soon, but they've been saying that for
six months. Right now, most of their energy is going into 1.4.
However, all of this is intended to be done as API compatible changes.
In the past, FLTK's CMake build system has not been well maintained --
this is the source of most of our problems with it. When problems
were raised, they generally responded with 'use ./configure' or 'use
the MSVC *.sln'. That doesn't work well for our ExternalProject_add
approach to libraries.
This is part of the reason for my assumption that you would use a
system-installed version of FLTK. That way, the OS package
distributors solved the problem of building FLTK on their old
system....
If you succeed in compiling FLTK (or using the Centos supplied one) --
and then getting the OpenVSP CMake to find that version of FLTK -- but
you still have problems, are they at compile time, or link time? If
they are compile problems, please post them. I'm not adverse to
figuring out more compatible ways of doing things if we're using
bleeding edge FLTK API calls.
OpenVSP's git repo tags every release. It should be easy to find any
numbered release like this:
https://github.com/ramcdona/OpenVSP/releases/tag/OpenVSP_3.6.0
https://github.com/ramcdona/OpenVSP/archive/OpenVSP_3.6.0.tar.gz
We moved from FLTK 1.3.2 'official' (with three of our own patches) to
the current testing version in November 2015 -- to gain retina display
support. These changes went in just before 3.5.0.
https://github.com/OpenVSP/OpenVSP/commit/b5e8c885c16c10b23b624927f5b9123d77d23286
The 1.3.2 version was the one that shipped with the first 2.9.0
'Alpha' version of the OpenVSP re-write in February 2014. You should
be able to compile OpenVSP against that version today.
Rob
> --
> You received this message because you are subscribed to the Google Groups
> "OpenVSP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openvsp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
I'm sorry you've had all this frustration.
On Linux, my assumption is that you don't build your own FLTK (and
most other libraries from the Libraries sub-project), instead, you
build against the system installed one. You tell the OpenVSP build
system this with VSP_USE_SYSTEM_FLTK=true and the like.
FLTK claims/strives to maintain compatibility with old versions -- it
has been a while since I have done this, but I've compiled OpenVSP
against some very old versions of FLTK in the past (1.1.10 ish I
think). I only recall one small API incompatibility to that version.
OpenVSP has gone to a custom-selected bleeding edge FLTK versions in
order to satisfy build problems on all the platforms we try to support
(not for some particular functionality in OpenVSP). The only somewhat
recent FLTK feature we knowingly support is retina display support on
OSX, but that should be conditionally compiled to protect for old
versions.
FLTK development is active, but they are slow to release new versions.
1.3.3 is well over a year old, tons has happened since then. 1.3.4 is
promised as a stable version soon, but they've been saying that for
six months. Right now, most of their energy is going into 1.4.
However, all of this is intended to be done as API compatible changes.
In the past, FLTK's CMake build system has not been well maintained --
this is the source of most of our problems with it. When problems
were raised, they generally responded with 'use ./configure' or 'use
the MSVC *.sln'. That doesn't work well for our ExternalProject_add
approach to libraries.
This is part of the reason for my assumption that you would use a
system-installed version of FLTK. That way, the OS package
distributors solved the problem of building FLTK on their old
system....
If you succeed in compiling FLTK (or using the Centos supplied one) --
and then getting the OpenVSP CMake to find that version of FLTK -- but
you still have problems, are they at compile time, or link time? If
they are compile problems, please post them. I'm not adverse to
figuring out more compatible ways of doing things if we're using
bleeding edge FLTK API calls.
OpenVSP's git repo tags every release. It should be easy to find any
numbered release like this:
https://github.com/ramcdona/OpenVSP/releases/tag/OpenVSP_3.6.0
https://github.com/ramcdona/OpenVSP/archive/OpenVSP_3.6.0.tar.gz
We moved from FLTK 1.3.2 'official' (with three of our own patches) to
the current testing version in November 2015 -- to gain retina display
support. These changes went in just before 3.5.0.
https://github.com/OpenVSP/OpenVSP/commit/b5e8c885c16c10b23b624927f5b9123d77d23286
The 1.3.2 version was the one that shipped with the first 2.9.0
'Alpha' version of the OpenVSP re-write in February 2014. You should
be able to compile OpenVSP against that version today.
Rob
> You received this message because you are subscribed to the Google Groups
> "OpenVSP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to openvsp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Glover George
Jul 31, 2016, 11:50:05 AM7/31/16
to OpenVSP
FLTK doesn't exist in the official RHEL/CentOS 6 repos, but it does exist in 7. However, it is trivial to compile it. I have no problems there. The problems come when building OpenVSP. I'll go through that process and post them. I probably should have just walked through that debugging process with you instead of complaining, but I had beat my head into the wall too much yesterday :D
Rob McDonald
Jul 31, 2016, 11:55:20 AM7/31/16
to ope...@googlegroups.com
I'm surprised FLTK doesn't exist in RHEL 6 -- FLTK goes back a long
time and has a long history of software that use it. I would expect
it to be version 1.1.X based, but I would think it would exist...
I'm sorry it was so frustrating, we can figure it out.
Rob
time and has a long history of software that use it. I would expect
it to be version 1.1.X based, but I would think it would exist...
I'm sorry it was so frustrating, we can figure it out.
Rob
Glover George
Aug 1, 2016, 11:36:24 AM8/1/16
to OpenVSP
1.1.10 does exist in EPEL, but that's not officially supported by RedHat and wouldn't be installable on our systems system-wide due to policy. The good thing is every version of fltk I've installed from source in my home directory installs smoothly from source on RHEL.
Reply all
Reply to author
Forward
0 new messages