FLTK 1.3.3 released on Nov 03, 2014

[Greg Ercolano]

Created at 14:23 Nov 03, 2014 by AlbrechtS

Even though FLTK 1.3.3 does not fix all STRs, we decided to release FLTK 1.3.3 as it contains many new features, bug fixes, and adaptations to new compiler releases.

CHANGES IN FLTK 1.3.3

New features and extensions

- New class Fl_Copy_Surface allows copying graphical data to the
  clipboard in a cross-platform way (STR #3058).
- Support for pasting graphical data from the clipboard to a widget.
- New class Fl_Image_Surface allows drawing into an Fl_Image object.
- Methods Fl::add_clipboard_notify() and Fl::remove_clipboard_notify()
  to get notifications whenever the clipboard changes (STR #2636).
- New method Fl_Window::wait_for_expose() (STR #3124, STR #3129).
- New bilinear scaling method for RGB images (STR #2869, STR #3062).
- New method Fl_Widget::top_window() (STR #2948).
- New method Fl_Widget::top_window_offset() (part of STR #2944).
- New Fl_Tree_Item methods label_x(), label_y(), label_w(), label_h().
- New methods Fl::enable_im() and Fl::disable_im() to enable/disable
  system Input Methods (IM).
- New methods Fl::add_system_handler() and Fl::remove_system_handler()
  to intercept low level system events.
- New FLTK scheme "gleam" (STR #2672).
- New method Fl::is_scheme() to compare the current scheme name.
- New method to set custom icons for windows (STR #2816),
  see Fl_Window::icon() for more info.
- New method to set any custom cursor, based on a Fl_RGB_Image object.
  Also changed fallback cursors to use this method, so that fallback
  cursors are handled in a platform independent manner (STR #2660).
- New ability to convert Fl_Pixmap to Fl_RGB_Image (STR #2659).
- Support for full screen windows over multiple monitors.
- New optional line numbers in Fl_Text_Display and options to control
  line numbers and word wrapping (on/off) in example test/editor.cxx.
- On Linux/Unix, class Fl_Native_File_Chooser uses file dialogs from
  the Gnome environment (provided by the libgtk dynamic library) if
  available, and falls back to Fl_File_Chooser if not (STR #3088).
  Use option Fl::OPTION_FNFC_USES_GTK to enable/disable this feature.
- New support for the Mac OS text input system that deals with character
  composition and input of languages with large character sets (e.g.
  Chinese and Japanese). This implementation has been reported to work
  well for Chinese. Superficial testing suggests it's also operational
  for Japanese. In-depth testing remains needed though.

Other improvements

- Many CMake improvements (e.g. STR #2962, 2977, 2994, 3045, 3055).
- Some autoconf, configure improvements.
- Removed 1024 bytes constraint in labels and browser lines (STR #2990).
- Mac OS version of Fl_Native_File_Chooser: when using filters in a
  save file dialog, the output file extension gets changed when the
  user modifies the output file type.
- Many Mac OS X improvements related to Fl_Sys_Menu_Bar.
- Improved Mac OS X keyboard handling of special keys or combinations.
- General Mac OS X improvements, incl. high resolution (Retina)
  displays, and support up to Mac OS X 10.10.
- Documentation improvements and clarifications.
- Printing support improvements, including GL windows.
- Many improvements related to Fl_Tree (some of them only as ABI
  breaking features, see below).
- Some static data has been made 'const' to improve memory usage
  with shared libraries.
- Don't grab navkeys with modifiers (CTRL, ALT), as the application
  may want them (STR #3104).
- Check compiler support of -fvisibility, -fvisibility-inlines-hidden,
  and use it, if available. Reduces shared library size.
- Drag'n'drop behaves better now: if text is dropped in the widget it
  comes from, then it works like cut and paste.
- Other improvements of DND handling when dragging text from other
  applications, e.g. Firefox and Thunderbird.
- Windows message WM_QUIT is processed like SIGTERM, i.e. as a
  request to terminate the program.
- Fluid no longer closes the code window when hitting ESC (STR #2997).
- Improved Fl_Widget::when() handling in Fl_Tabs (STR #2939).
- Improved support for more recent compilers (clang and gcc) that
  issue more warnings, and fixed some 32-/64-bit compilation issues.
- Added method Fl_Window::clear_modal_states() to make it possible
  to remove the modal or non-modal state from a window (STR #3123).

Bug fixes

- Fixed word selection dragging in text input (STR #3014).
- Fixed border padding for special cases (STR #3061, Windows only).
- Fixed crash if Fl_Window::flush() called while window not shown()
  (STR #3028).
- Fixed segfault in fl_set_fonts_xft.cxx when loading fonts not named
  as expected (STR #2976).
- Fixed a memory leak in font loading/allocation (STR #3069).
- Fixed minor memory leaks in handling/freeing of X11 objects.
- Fixed OS X fl_read_image() and Fl_Paged_Device::print_window_part()
  when using a Retina display.
- Fixed MinGW build if configure didn't find strcasecmp() (STR #2994).
- Fixed access of protected member under Linux/Unix (STR #2903).
- Fixed various Mac specific OpenGL issues (STR #2944)
- Fixed PostScript printing with non-english locale (STR #3130).
- Fixed a regression in Fl_File_Chooser since FLTK 1.1.8: the
  Enter key now selects the file again.
- Fixed a bug in Fl_Native_File_Chooser (Windows) for some file name
  input filters (STR #3101).
- Fixed out-of-bounds memory access in Fl_Text_Display (STR #2730).

FLTK 1.3.3 ABI FEATURES

To enable the following ABI features, put:

  #define FLTK_ABI_VERSION 10303

..at the top of your FL/Enumerations.H and rebuild FLTK and your app.

- Added Fl_Window::shape(const Fl_Image*) to create arbitrarily-shaped
  windows
- Made Fl_Help_View::handle() public and Fl_Help_View::draw() protected
  to enable inheritance and for consistency (STR #2834).
  Note: both methods were private.
- Made Fl_Scroll::recalc_scrollbars() protected so that it can be used
  in derived widgets to calculate scrollbar visibility and positions.
- Added Fl_Table::tab_cell_nav() for controlling Tab key navigation of table
- Added Fl_Tree::get_selected_items(), returns the selected items as an array
- Added Fl_Tree::item_draw_callback(), letting one define a custom draw
  function for Fl_Tree_Item's.
- Fl_Tree: various related changes:
    o Added horizontal scrollbar
    o Separated draw() and tree size calculation
    o Added new public methods:
        > resize()           -- uses optimized dim calc, avoids tree recalc
        > next_item()        -- added parameters: direction, visibility
        > extend_selection() -- added parameters, improved algorithm
        > calc_dimensions()  -- calc tix/y/w/h, tox/y/w/h and scrollbars
        > calc_tree()        -- calc tree_w/tree_h
        > recalc_tree()      -- schedules calc_tree()
        > first_visible_item(), last_visible_item(), next_visible_item()
        > first_selected_item(), last_selected_item(), next_selected_item()
    o Added protected variables:
        > _tix/y/w/h      -- tree widget 'inner' dimension
        > _tox/y/w/h      -- tree widget 'outer' dimension
        > _tree_w,_tree_h -- entire tree hierarchy width/height
    o Deprecated:
        > item_clicked() -- use callback_item() instead
        > first_visible() -- use first_visible_item() instead
        > last_visible() -- use last_visible_item() instead

- Fl_Tree_Item: various related changes:
    o Added Fl_Tree ptr: needed for auto-recalc when item modified directly
    o Added new methods tree(), recalc_tree()
    o Added new ctor that accepts Fl_Tree*
    o draw() parameters changed to include tree size calculations
    o Deprecated:
       > ctor using Fl_Tree_Prefs parameter (Fl_Tree* version better,
         and must be used for 1.3.3 ABI features to work correctly)
       > next_displayed() -- use next_visible() instead
       > prev_displayed() -- use prev_visible() instead
- test/tree: added tests for newly added features

---

[Sanel Zukan]

Great list of changes and new features!

Thanks everyone who made this possible.

Best,
Sanel

On 11/03/14,Greg Ercolano wrote:

> /Created at 14:23 Nov 03, 2014 by AlbrechtS/

> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>

[Kevin Ingwersen (Ingwie Phoenix)]

Phew, thats quite a long list! I’m glad it happened - because there were some OS X compiler issues that had to do with the „friend“ keyword. Was minor, fixed at some point but it wasn’t fixed in stock FLTK 1.3.2 :). Great work guys!

--
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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Bäuerle]

Sanel Zukan wrote:
>
> Great list of changes and new features!
>
> Thanks everyone who made this possible.

I want to thank all involved people too (in particular Albrecht
who pushed this release).

[Albrecht Schlosser]

You're welcome.

I'd like to add in particular Greg who skyped with me several hours to
fix the issues on the server side, since this was the first release on
the server hosted by Greg. And also special thanks to Greg for all the
time he spent to build and manage this server since the crash in April
2003.

But many thanks also to all the other dev's and other contributors who
helped testing and fixed STR's in the weeks before the release.

[Remy Oukaour]

Thank you to everyone who has been updating and maintaining FLTK. It's a great project that fulfills its role very well.

A couple years ago I rewrote a scientific visualization program, which involved replacing GLUT with FLTK -- I made the choice because it's written in C++, it's cross-platform, and it's not a full-blown framework like Qt. The redesign took only a couple weeks, and while the app has evolved since then, it's been easy to add new features and refactor as necessary. The process of reporting bugs and requesting features is also easy to use, and the devs (Manolo, Lauri, Greg, and everyone else) have been nothing but polite and helpful.

I eventually switched from 1.3.2 to the weekly builds with the new ABI enabled, so 1.3.3 is a nice checkpoint to have, and I'm looking forward to 1.4.0.

[Richard Shaw]

Quick question regarding the 1.3.3 release...

Is the CMake build considered a viable or the preferred build method yet?

Thanks,

Richard

[Greg Ercolano]

On 11/05/14 10:14, Richard Shaw wrote:
> Quick question regarding the 1.3.3 release...
>
> Is the CMake build considered a viable or the preferred build method yet?

I think I'll let Albrecht weigh in on this.

But my understanding from talking to him during the 1.3.3 release
process is that cmake is still "experimental", but getting better (viable),
and is a direction I believe he wants things to go in the future
to perhaps get us away from autoconf.

It would also help automate the construction of the IDE files,
and get us away from having to include them in the distro,
so that we'd no longer need a populated "ide" directory.
(cmake would construct them all on the user's build platform)

Going this direction would, however, put a dependency on having cmake
installed to build FLTK on any platform (including windows), and we're
just not there yet.

The devs will probably need a long period of evaluating cmake as the
new default before making it the new 'official' FLTK build technique.

I think Albrecht also has a todo list of things that need to be
resolved in our current cmake setup. Not sure if he posted this
in fltk.coredev or not.

[Albrecht Schlosser]

On 05.11.2014 19:38, Greg Ercolano wrote:
> On 11/05/14 10:14, Richard Shaw wrote:
>> Quick question regarding the 1.3.3 release...
>>
>> Is the CMake build considered a viable or the preferred build method yet?
>
> I think I'll let Albrecht weigh in on this.

I'm here...

> But my understanding from talking to him during the 1.3.3 release
> process is that cmake is still "experimental", but getting better (viable),

Yep. It is not yet complete, nor is it fully tested. For instance,
shared library builds do not work on some platforms, some support files
are not yet copied during the build process (e.g. demo.menu, but there
are more), fltk-config is far from usable, to mention only some issues.

But there is one really interesting point: nobody tested creating Xcode
IDE files in the development process until a few days ago. I asked if
someone would try, and Manolo was so kind to test it. Except a few
(known or at least suspected) issues (see above) it worked, and he could
build the library and test programs. That was more than one could
expect, and it lets me hope that we can also get other IDE files "for
free", e.g. Eclipse, Borland, CodeBlocks, Watcom, Ninja, all versions of
Visual Studio from VS 6 to VS 2013, ...

> and is a direction I believe he wants things to go in the future
> to perhaps get us away from autoconf.

I'd like to, if we can make it work at least as well as autoconf, and if
we can get consensus about it (i.e. the devs and/or maybe the majority
of users: we could do a poll on our home page). Nothing planned yet, but
I'm trying to get it running, and Michael Surette is supporting us a
lot. More help would be appreciated, BTW, but I'm trying to learn as
much as I can to be able to do the CMake part myself.

> It would also help automate the construction of the IDE files,
> and get us away from having to include them in the distro,
> so that we'd no longer need a populated "ide" directory.
> (cmake would construct them all on the user's build platform)

Yep, that's a big advantage. There would be only one point in one of the
CMakeLists.txt files where we would have to add a new file or remove
one, and no hassle with dependencies on different platforms, because
CMake does its own dependency checks. IMHO CMake is much easier to
understand than autoconf, and I think that we don't have one developer
in our team who really knows autoconf well. CMake is also good for
cross-compiling environments.

> Going this direction would, however, put a dependency on having cmake
> installed to build FLTK on any platform (including windows), and we're
> just not there yet.

Unfortunately yes, but I believe that more and more open source projects
are using CMake, so this seems to be acceptable to me. The most
problematic part would be the Windows platform, and AFAICT the CMake
download is simple (a usual Windows installer). The IDE files can be
created "with two clicks" (selecting the source and build directories).
Pretty simple.

> The devs will probably need a long period of evaluating cmake as the
> new default before making it the new 'official' FLTK build technique.

At least there will be a long period of having both systems, and users
can select which one to use. Ideally. Later we _might_ abandon autoconf
completely.

> I think Albrecht also has a todo list of things that need to be
> resolved in our current cmake setup. Not sure if he posted this
> in fltk.coredev or not.

Michael Surette posted one recently.

That's my personal view only, but I hope it works and we can get CMake
running...

[Richard Shaw]

Thanks for the update!

I have a patch that I needed to get things to install correctly on Fedora (multilib mainly). Some of it is a hack which would need a better solution to accept upstream.

I don't know of any system where man files go in /usr/man or /usr/local/man...

diff -Naur fltk-1.3.3.orig/CMake/install.cmake fltk-1.3.3.cmake/CMake/install.cmake

--- fltk-1.3.3.orig/CMake/install.cmake 2014-09-26 19:41:06.000000000 -0500

+++ fltk-1.3.3.cmake/CMake/install.cmake 2014-11-05 13:17:02.541916398 -0600

@@ -74,7 +74,7 @@

    macro(INSTALL_MAN FILE LEVEL)

    install(FILES

       ${FLTK_SOURCE_DIR}/documentation/src/${FILE}.man

-      DESTINATION man/man${LEVEL}

+      DESTINATION share/man/man${LEVEL}

       RENAME ${FILE}.${LEVEL}

    )

    endmacro(INSTALL_MAN FILE LEVEL)

@@ -86,4 +86,6 @@

    INSTALL_MAN(checkers 6)

    INSTALL_MAN(sudoku 6)

 

+   install(PROGRAMS ${CMAKE_BINARY_DIR}/fltk-config DESTINATION bin)

+

 endif(UNIX)

Multilib systems usr lib64 for 64bit libraries, this is a hack as the cmake macro for Fedora/rpmbuild sets this variable.

diff -Naur fltk-1.3.3.orig/CMake/macros.cmake fltk-1.3.3.cmake/CMake/macros.cmake

--- fltk-1.3.3.orig/CMake/macros.cmake 2014-10-11 20:24:04.000000000 -0500

+++ fltk-1.3.3.cmake/CMake/macros.cmake 2014-11-05 12:49:13.194853451 -0600

@@ -66,8 +66,8 @@

     install(TARGETS ${LIBRARY_NAME}

         EXPORT FLTK-Targets

         RUNTIME DESTINATION bin

-        LIBRARY DESTINATION lib

-        ARCHIVE DESTINATION lib

+        LIBRARY DESTINATION lib${LIB_SUFFIX}

+        ARCHIVE DESTINATION lib${LIB_SUFFIX}

         )

 

     list(APPEND FLTK_LIBRARIES "${LIBRARY_NAME}")

Same here

diff -Naur fltk-1.3.3.orig/CMake/setup.cmake fltk-1.3.3.cmake/CMake/setup.cmake

--- fltk-1.3.3.orig/CMake/setup.cmake 2014-10-04 19:03:27.000000000 -0500

+++ fltk-1.3.3.cmake/CMake/setup.cmake 2014-11-05 12:51:03.996078426 -0600

@@ -58,7 +58,7 @@

    set(FLTK_CONFIG_PATH FLTK/.framework/Resources/CMake)

    set(FLTK_EXAMPLES_PATH share/fltk-examples)

 else()

-   set(FLTK_CONFIG_PATH lib/fltk)

+   set(FLTK_CONFIG_PATH lib${LIB_SUFFIX}/fltk)

    set(FLTK_EXAMPLES_PATH share/fltk-examples)

 endif(WIN32 AND NOT CYGWIN)

 

I know we discussed the GNUInstallDirs module before and it sounds like we're not quite ready to require that minimum version of CMake yet so I'm suggesting using FLTK specific variables which can be overridden by the end user, perhaps:

FLTK_BINDIR

FLTK_LIBDIR

FLTK_INCLUDEDIR

FLTK_MANDIR

Then set these to good default values (perhaps per system if helpful?) 

Something like:

set(FLTK_BINDIR bin CACHE PATH "Path to install binaries. Relative paths will be prefixed with CMAKE_INSTALL_PREFIX.")

I can probably come up with more good tweaks but I think I should put those in separate threads as time allows.

Thanks,

Richard

[Albrecht Schlosser]

On 06.11.2014 16:57, Richard Shaw wrote:
> Thanks for the update!

Welcome.

> I have a patch that I needed to get things to install correctly on
> Fedora (multilib mainly). Some of it is a hack which would need a better
> solution to accept upstream.

Thank you very much for the patches. We appreciate your support.

Unfortunately this mailing list (fltk.general) is not appropriate for
patches like these. Please use fltk.coredev ("fltkcoredev") for
discussion and our STR system for posting patches. We prefer "modular"
patches, i.e. one STR for one (or maybe a few) _related_ patches. This
makes sure that patches don't get lost in the noise of the mailing list,
and it is easier to apply and discuss one patch at a time. You can post
patches as single files (attachments, not inline) so they can be
downloaded and applied easily, or updated if necessary. TIA.

See http://www.fltk.org/str.php

I'll have a look at the patches, when time permits. Meanwhile I'd
appreciate if you could post the patches on the STR system anyway. This
would help a lot.

> I don't know of any system where man files go in /usr/man or
> /usr/local/man...

[... patches elided ...]

Sorry, I don't have time to comment these patches now.

> I know we discussed the GNUInstallDirs module before and it sounds like
> we're not quite ready to require that minimum version of CMake yet so
> I'm suggesting using FLTK specific variables which can be overridden by
> the end user, perhaps:
>
> FLTK_BINDIR
> FLTK_LIBDIR
> FLTK_INCLUDEDIR
> FLTK_MANDIR
>
> Then set these to good default values (perhaps per system if helpful?)
>
> Something like:
>
> set(FLTK_BINDIR bin CACHE PATH "Path to install binaries. Relative paths
> will be prefixed with CMAKE_INSTALL_PREFIX.")

Sounds good, thanks.

> I can probably come up with more good tweaks but I think I should put
> those in separate threads as time allows.

Please see above (STR system), and TIA.

Thanks again,
Albrecht

[Albrecht Schlosser]

On 06.11.2014 16:57 Richard Shaw wrote:

> I have a patch that I needed to get things to install correctly on
> Fedora (multilib mainly). Some of it is a hack which would need a better
> solution to accept upstream.

With "upstream" you mean the FLTK develoment team ?

> I don't know of any system where man files go in /usr/man or
> /usr/local/man...
>

> diff -Naur fltk-1.3.3.orig/CMake/install.cmake
> fltk-1.3.3.cmake/CMake/install.cmake
> --- fltk-1.3.3.orig/CMake/install.cmake2014-09-26 19:41:06.000000000 -0500
> +++ fltk-1.3.3.cmake/CMake/install.cmake2014-11-05 13:17:02.541916398 -0600

> @@ -74,7 +74,7 @@
> macro(INSTALL_MAN FILE LEVEL)
> install(FILES
> ${FLTK_SOURCE_DIR}/documentation/src/${FILE}.man
> - DESTINATION man/man${LEVEL}
> + DESTINATION share/man/man${LEVEL}
> RENAME ${FILE}.${LEVEL}
> )
> endmacro(INSTALL_MAN FILE LEVEL)
> @@ -86,4 +86,6 @@
> INSTALL_MAN(checkers 6)
> INSTALL_MAN(sudoku 6)
> + install(PROGRAMS ${CMAKE_BINARY_DIR}/fltk-config DESTINATION bin)
> +
> endif(UNIX)

I committed the first hunk of this patch, because it's obvious.
svn r 10440.

fltk-config is not yet ready for use when generated with CMake. That
might be one reason why Michael did not yet add the installation. I
don't know.

Particularly you should not use it for a Fedora distribution. Use the
autoconf/make generated one please. CMake is still experimental!

I hesitated to add this (hunk #2) also for another reason: It's not only
UNIX that needs to install fltk-config, but also MinGW, Cygwin,
whatever. Same for man pages, btw.. We need to make a better decision at
this point in install.cmake.

> Multilib systems usr lib64 for 64bit libraries, this is a hack as the
> cmake macro for Fedora/rpmbuild sets this variable.
>
> diff -Naur fltk-1.3.3.orig/CMake/macros.cmake
> fltk-1.3.3.cmake/CMake/macros.cmake

> --- fltk-1.3.3.orig/CMake/macros.cmake2014-10-11 20:24:04.000000000 -0500
> +++ fltk-1.3.3.cmake/CMake/macros.cmake2014-11-05 12:49:13.194853451 -0600

> @@ -66,8 +66,8 @@
> install(TARGETS ${LIBRARY_NAME}
> EXPORT FLTK-Targets
> RUNTIME DESTINATION bin
> - LIBRARY DESTINATION lib
> - ARCHIVE DESTINATION lib
> + LIBRARY DESTINATION lib${LIB_SUFFIX}
> + ARCHIVE DESTINATION lib${LIB_SUFFIX}
> )
> list(APPEND FLTK_LIBRARIES "${LIBRARY_NAME}")
>
>
> Same here
>
> diff -Naur fltk-1.3.3.orig/CMake/setup.cmake
> fltk-1.3.3.cmake/CMake/setup.cmake

> --- fltk-1.3.3.orig/CMake/setup.cmake2014-10-04 19:03:27.000000000 -0500
> +++ fltk-1.3.3.cmake/CMake/setup.cmake2014-11-05 12:51:03.996078426 -0600

> @@ -58,7 +58,7 @@
> set(FLTK_CONFIG_PATH FLTK/.framework/Resources/CMake)
> set(FLTK_EXAMPLES_PATH share/fltk-examples)
> else()
> - set(FLTK_CONFIG_PATH lib/fltk)
> + set(FLTK_CONFIG_PATH lib${LIB_SUFFIX}/fltk)
> set(FLTK_EXAMPLES_PATH share/fltk-examples)
> endif(WIN32 AND NOT CYGWIN)

> I know we discussed the GNUInstallDirs module before and it sounds like
> we're not quite ready to require that minimum version of CMake yet so
> I'm suggesting using FLTK specific variables which can be overridden by
> the end user, perhaps:
>
> FLTK_BINDIR
> FLTK_LIBDIR
> FLTK_INCLUDEDIR
> FLTK_MANDIR
>
> Then set these to good default values (perhaps per system if helpful?)
>
> Something like:
>
> set(FLTK_BINDIR bin CACHE PATH "Path to install binaries. Relative paths
> will be prefixed with CMAKE_INSTALL_PREFIX.")

I'd like to have all these ${LIB_SUFFIX} usages isolated and assigned
only at one place, maybe somewhere at the beginning as you suggested.
Then use FLTK-defined variables later. So we could also later change it
easily (at least I hope so) when we come to the decision to use
GNUInstallDirs. Maybe.

> I can probably come up with more good tweaks but I think I should put
> those in separate threads as time allows.

As said already: looking forward to your contributions (in
fltk.development and/or our STR system). Thanks.

[Richard Lemieux]

Hi,

I installed fltk-1.3.3 from source on my Slackware based system but my app no longer links.  The error is,

  /usr/X11R6/lib64/libfltk_gl.so: undefined reference to `Fl_XFont_On_Demand::value()

This problem has been reported already but I did not see a fix yet.  Is there any simple work around?

I have been building this app with 1.3.2 for a while now.  First time I meet this.

If this has any relevance, the configure options are,

./configure \
  --prefix=/usr \
  --sysconfdir=/etc \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --localstatedir=/var \
  --enable-gl \
  --enable-largefile \
  --enable-shared \
  --enable-threads \
  --enable-xft

[MacArthur, Ian (Selex ES, UK)]

> I installed fltk-1.3.3 from source on my Slackware based system but my
> app no longer links. The error is,

> /usr/X11R6/lib64/libfltk_gl.so: undefined reference to
> `Fl_XFont_On_Demand::value()

That's odd. I can only report that "it works for me", though that is not helpful here.

Hmm, though you have 64-bit shared objects, I wonder if that's an issue, I don't think my tests cover that.


Though we looked at the ABI compatibility test output, I thought we'd decided this looks OK... Lauri, Greg, Albrecht, others, would know better than me...

What link order do you have in your Makefile? I wonder if there's something odd about the linkage order or something that is exposing a problem here?



FWIW, and assuming you do have XFT working, then XFontStruct* Fl_XFont_On_Demand::value() is defined in fl_font_xft.cxx near line 540, and prototyped (and public) in x.H near line 125, so should be visible in the generated code.

Was there anything more in the error message? Perhaps the decorated name does not match for some reason, etc.?

> This problem has been reported already but I did not see a fix yet. Is
> there any simple work around?

Can you try static linking? It looks like it might be a dynamic linking issue, at a guess...

Is there some reason why you opted for dynamic linking for your app.? It is rarely the better choice with fltk apps.


Where was it reported?

> I have been building this app with 1.3.2 for a while now. First time I
> meet this.

> If this has any relevance, the configure options are,

I doubt it's the config options. It looks like something related to symbol visibility in the ABI...

> ./configure \
> --prefix=/usr \
> --sysconfdir=/etc \
> --libdir=/usr/lib${LIBDIRSUFFIX} \
> --localstatedir=/var \

... fine...

> --enable-gl \
> --enable-largefile \
> --enable-shared \
> --enable-threads \
> --enable-xft

... these are probably unnecessary; these are the default settings for 1.3.x anyway.





Selex ES Ltd
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.
********************************************************************

[Richard Lemieux]

On Wednesday, December 17, 2014 5:26:48 AM UTC-5, MacArthur, Ian (Selex ES, UK) wrote:

What link order do you have in your Makefile? I wonder if there's something odd about the linkage order or something that is exposing a problem here?

 

  g++  -fschedule-insns2 -ffast-math -march=x86-64 -mmmx -msse -mfpmath=sse  -o sonasoundp globalsInit.o callbacks.o paInit.o aio.o cb.o cct.o erc.o controls_ui.o fft.o glDraw.o glew.o lpc.o numerical.o panels_ui.o service_ui.o sonogram.o soundfile_wrap.o startup_stats.o window.o main.o glfw_x11_time.o /usr/lib64/libportaudio.a -L/usr/X11R6/lib64  -lfltk -lfltk_gl -lXxf86vm  -lGL -lGLU -lXext -lX11 -lXft -lXinerama -lXfixes -lXcursor  -L/usr/lib64  -lfftw3_threads -lfftw3 -lsndfile -ljack -lasound  -lfontconfig -lpthread -ldl  -lm

/usr/X11R6/lib64/libfltk_gl.so: undefined reference to `Fl_XFont_On_Demand::value()'
collect2: error: ld returned 1 exit status

FWIW, and assuming you do have XFT working, then XFontStruct* Fl_XFont_On_Demand::value() is defined in fl_font_xft.cxx near line 540, and prototyped (and public) in x.H near line 125, so should be visible in the generated code.

Was there anything more in the error message? Perhaps the decorated name does not match for some reason, etc.?


> This problem has been reported already but I did not see a fix yet.  Is
> there any simple work around?

Can you try static linking? It looks like it might be a dynamic linking issue, at a guess...

Static linking works fine, thank you.  That solves my problem.

g++  -fschedule-insns2 -ffast-math -march=x86-64 -mmmx -msse -mfpmath=sse  -o sonasoundp globalsInit.o callbacks.o paInit.o aio.o cb.o cct.o erc.o controls_ui.o fft.o glDraw.o glew.o lpc.o numerical.o panels_ui.o service_ui.o sonogram.o soundfile_wrap.o startup_stats.o window.o main.o glfw_x11_time.o /usr/lib64/libportaudio.a /usr/X11R6/lib64/libfltk.a /usr/X11R6/lib64/libfltk_gl.a  -L/usr/X11R6/lib64  -lXxf86vm  -lGL -lGLU -lXext -lX11 -lXft -lXinerama -lXfixes -lXcursor  -L/usr/lib64  -lfftw3_threads -lfftw3 -lsndfile -ljack -lasound  -lfontconfig -lpthread -ldl  -lm

# There is no error and the program works fine.  Thanks again.
 

Is there some reason why you opted for dynamic linking for your app.? It is rarely the better choice with fltk apps.

On MingW32 I link statically.  In Linux, I didn't care yet but from now on I will use the static link in Linux as well.

Where was it reported?

In the fltkgeneral maybe 15-20 posts ago.  The person said that he install 1.3.3 but one test failed to link with the same error I got.

By the way is there a strong advantage to using the fltk libraries from the /usr/X11R6/lib64 as opposed to the ones found in /usr/lib64?  This is something that is not clear to me yet.

[MacArthur, Ian (Selex ES, UK)]

> > What link order do you have in your Makefile? I wonder
> > if there's something odd about the linkage order or
> > something that is exposing a problem here?
 

> -lfltk -lfltk_gl -lXxf86vm  -lGL -lGLU -lXext -lX11 -lXft

Ah, that's interesting...

libfltk resolves symbols that are needed by libfltk_gl so really ought to be listed after it.

I wonder if trying...

-lfltk_gl -lfltk -lXxf86vm -lGL -lGLU -lXext -lX11 -lXft

...etc. would work any better.

Be interested to hear the outcome.

> > Can you try static linking?

> # There is no error and the program works fine.

OK, glad that helps.

 
> > Is there some reason why you opted for dynamic linking
> > for your app.? It is rarely the better choice with fltk apps.

> On MingW32 I link statically.  In Linux, I didn't care yet
> but from now on I will use the static link in Linux as well.

Dynamic linking a lib can be a win if many apps are using the lib, or if the lib itself is large.
I find that neither is (generally) true for fltk apps, so pretty much always static link.
YMMV.

> By the way is there a strong advantage to using the
> fltk libraries from the /usr/X11R6/lib64 as opposed
> to the ones found in /usr/lib64? 

I could not say.

FWIW, I seldom "install" fltk at all, since it works perfectly well from the build location (and I tend to have multiple, potentially incompatible, fltk versions on the go anyway, so installation is not really an option for me...)
Judicious use of fltk-config makes it easy to have multiple copies of fltk and use each directly from its build tree.

[Albrecht Schlosser]

On 17.12.2014 13:06 Richard Lemieux wrote:

> On Wednesday, December 17, 2014 5:26:48 AM UTC-5, MacArthur, Ian (Selex
> ES, UK) wrote:
>
>

> What link order do you have in your Makefile? I wonder if there's
> something odd about the linkage order or something that is exposing
> a problem here?
>

> g++ -fschedule-insns2 -ffast-math -march=x86-64 -mmmx -msse
> -mfpmath=sse -o sonasoundp globalsInit.o callbacks.o paInit.o aio.o
> cb.o cct.o erc.o controls_ui.o fft.o glDraw.o glew.o lpc.o numerical.o
> panels_ui.o service_ui.o sonogram.o soundfile_wrap.o startup_stats.o
> window.o main.o glfw_x11_time.o /usr/lib64/libportaudio.a

> -L/usr/X11R6/lib64 -lfltk -lfltk_gl -lXxf86vm -lGL -lGLU -lXext -lX11

> -lXft -lXinerama -lXfixes -lXcursor -L/usr/lib64 -lfftw3_threads
> -lfftw3 -lsndfile -ljack -lasound -lfontconfig -lpthread -ldl -lm
>

> /usr/X11R6/lib64/libfltk_gl.so: undefined reference to
> `Fl_XFont_On_Demand::value()'

> collect2: error: ld returned 1 exit status

Hmm. Obviously libfltk_gl.so includes a reference to
Fl_XFont_On_Demand::value(), and this is not exported from libfltk.so.

Here's a small patch:

Index: FL/x.H
===================================================================
--- FL/x.H (revision 10486)
+++ FL/x.H (working copy)
@@ -114,7 +114,7 @@
// With Xlib / X11 fonts, fl_xfont will return the current selected font.
// With XFT / X11 fonts, fl_xfont will attempt to return the bitmap
"core" font most
// similar to (usually the same as) the current XFT font.
-class Fl_XFont_On_Demand
+class FL_EXPORT Fl_XFont_On_Demand
{
public:
Fl_XFont_On_Demand(XFontStruct* p = NULL) : ptr(p) { }


The short form: add FL_EXPORT in line 117 of FL/x.H.

> Can you try static linking? It looks like it might be a dynamic
> linking issue, at a guess...

Yep, so do I.

Richard, can you please try the above patch with dynamic linking? This
would help to verify the problem so that we know this is the correct fix.

But before you do this, please try what happens if you revert the order
of the fltk libs as Ian suggested. This should be done anyway, but I
don't think that it will help here. So please do two tests and report
the outcome:

(1) reorder libs so that libfltk_gl is before libfltk (both static and
shared builds)

I assume this will give the same error in the shared build.

(2) Apply the patch above, and link shared again.

I assume this will work. Hopefully.

Thanks for your assistance.

> Static linking works fine, thank you. That solves my problem.

Fine, but please try again with the patch to help us fix it.

> Is there some reason why you opted for dynamic linking for your
> app.? It is rarely the better choice with fltk apps.
>

> On MingW32 I link statically. In Linux, I didn't care yet but from now
> on I will use the static link in Linux as well.

Are you sure you linked dynamically on Linux before? I assume that this
problem would also have been visible in FLTK 1.3.2 when linking shared.
Maybe you didn't build the shared libs, and so the linker used the
static libs as a fallback.

> Where was it reported?
>
>
> In the fltkgeneral maybe 15-20 posts ago. The person said that he
> install 1.3.3 but one test failed to link with the same error I got.

I would be surprised if this was not the case with 1.3.2, but maybe
there was something else going on (no shared libs available?).

> By the way is there a strong advantage to using the fltk libraries from

> the /usr/X11R6/lib64 as opposed to the ones found in /usr/lib64? This

> is something that is not clear to me yet.

Generally there's no advantage of any directory. But if you build from
source, then I'd recommend either not to install the FLTK libs at all
(as Ian suggested), or to remove the system libs (if you installed any).

The two different directories make me think that the libs in
/usr/X11R6/lib64 are installed by a system package - maybe FLTK itself
or any app that needs FLTK.

Your configure lines in your previous post say:

./configure \
--prefix=/usr \
...
--libdir=/usr/lib${LIBDIRSUFFIX} \


so I *assume* that you installed _your_ version in /usr/lib64, and that
should be the version you use for building your apps, of course.
Otherwise you wouldn't need to build FLTK at all, if there is a system
package installed - however, this may be an older version and you might
want the newest version, so you build from source.

The minimal option you should consider is to remove the fltk-devel or
fltk-dev package to remove the FLTK headers of older releases installed
by your linux distro.

[Richard Lemieux]

On Wednesday, December 17, 2014 8:03:15 AM UTC-5, Albrecht Schlosser wrote:

Hmm. Obviously libfltk_gl.so includes a reference to
Fl_XFont_On_Demand::value(), and this is not exported from libfltk.so.

Here's a small patch:

Index: FL/x.H
===================================================================
--- FL/x.H      (revision 10486)
+++ FL/x.H      (working copy)
@@ -114,7 +114,7 @@
 // With Xlib / X11 fonts, fl_xfont will return the current selected font.
 // With XFT / X11 fonts, fl_xfont will attempt to return the bitmap "core" font most
 // similar to (usually the same as) the current XFT font.
-class Fl_XFont_On_Demand
+class FL_EXPORT Fl_XFont_On_Demand
 {
 public:
   Fl_XFont_On_Demand(XFontStruct* p = NULL) : ptr(p) { }


The short form: add FL_EXPORT in line 117 of FL/x.H.

 

Richard, can you please try the above patch with dynamic linking? This

would help to verify the problem so that we know this is the correct fix.

But before you do this, please try what happens if you revert the order
of the fltk libs as Ian suggested. This should be done anyway, but I
don't think that it will help here. So please do two tests and report
the outcome:

(1) reorder libs so that libfltk_gl is before libfltk (both static and
shared builds)
 

Done.  The ordering of the libs in the link as above has no effect and I still get the error message.

I assume this will give the same error in the shared build.

True

(2) Apply the patch above, and link shared again.

I assume this will work. Hopefully.

True.  The patch worked.  The order of the libs in the link has no effect whatsoever with gcc; I tried both '-lfltk -lfltk_gl' and '-lfltk_gl -lfltk' and both link correctly.  It has been many years now that the ordering of the libs on the command line is irrelevant with gcc.  Granted that was critical in the early days, but now it seems that the linker finds the proper ordering by itself.  I may be wrong...

Thanks for your assistance.

Its a pleasure.  FLTK is such a nice toolkit when doing straightforward things.

Are you sure you linked dynamically on Linux before? I assume that this
problem would also have been visible in FLTK 1.3.2 when linking shared.
Maybe you didn't build the shared libs, and so the linker used the
static libs as a fallback.

That's a possibility. One of my 1.3.2 packages has no shared libraries in, just the static one.  But I can't tell for sure which package I was using yesterday since I have two 1.3.2  packages and I can't tell which one was installed before I started installing 1.3.3 packages.  Sorry about that.

I would be surprised if this was not the case with 1.3.2, but maybe
there was something else going on (no shared libs available?).

The shared libs were there with 1.3.2

> By the way is there a strong advantage to using the fltk libraries from
> the /usr/X11R6/lib64 as opposed to the ones found in /usr/lib64?  This
> is something that is not clear to me yet.

Generally there's no advantage of any directory. But if you build from
source, then I'd recommend either not to install the FLTK libs at all
(as Ian suggested), or to remove the system libs (if you installed any).

The two different directories make me think that the libs in
/usr/X11R6/lib64 are installed by a system package - maybe FLTK itself
or any app that needs FLTK.

The /usr/X11R6/lib64 directory is just a symlink to /usr/lib64 so there is just one set of fltk libraries.  Those are not leftovers from a previous install.  I usually care of removing things I no longer need.
 

Your configure lines in your previous post say:

./configure \
   --prefix=/usr \
   ...
   --libdir=/usr/lib${LIBDIRSUFFIX} \


so I *assume* that you installed _your_ version in /usr/lib64, and that
should be the version you use for building your apps, of course.
Otherwise you wouldn't need to build FLTK at all, if there is a system
package installed - however, this may be an older version and you might
want the newest version, so you build from source.

The minimal option you should consider is to remove the fltk-devel or
fltk-dev package to remove the FLTK headers of older releases installed
by your linux distro.

Thanks so much for your help.  Now I am back to solving issues I have with OpenGL.

[Richard Lemieux]

On Wednesday, December 17, 2014 7:40:47 AM UTC-5, MacArthur, Ian (Selex ES, UK) wrote:

> > What link order do you have in your Makefile? I wonder
> > if there's something odd about the linkage order or
> > something that is exposing a problem here?
 

>  -lfltk -lfltk_gl -lXxf86vm  -lGL -lGLU -lXext -lX11 -lXft


Ah, that's interesting...

libfltk resolves symbols that are needed by libfltk_gl so really ought to be listed after it.

I wonder if trying...

-lfltk_gl -lfltk -lXxf86vm  -lGL -lGLU -lXext -lX11 -lXft

...etc. would work any better.

I followed your suggestion and changed the order to '-lfltk_gl -lfltk' but I still got the same error message from the linker.  I will try Albrecht patch.

Be interested to hear the outcome.

Dynamic linking a lib can be a win if many apps are using the lib, or if the lib itself is large.
I find that neither is (generally) true for fltk apps, so pretty much always static link.
YMMV.

I agree entirely but I usually don't care since there are so many libraries floating around and they sometimes need to be built with specific options.  I will try to embed more libraries statically in the future since this solves distribution issues.

> By the way is there a strong advantage to using the
> fltk libraries from the /usr/X11R6/lib64 as opposed
> to the ones found in /usr/lib64? 

I could not say.

FWIW, I seldom "install" fltk at all, since it works perfectly well from the build location (and I tend to have multiple, potentially incompatible, fltk versions on the go anyway, so installation is not really an option for me...)
Judicious use of fltk-config makes it easy to have multiple copies of fltk and use each directly from its build tree.

Good idea.  I usually build packages since others might want to compile my code and they likely would use a package themselves.

[Albrecht Schlosser]

On 17.12.2014 15:43 Richard Lemieux wrote:
>
>
> On Wednesday, December 17, 2014 8:03:15 AM UTC-5, Albrecht Schlosser wrote:
>
>

> Hmm. Obviously libfltk_gl.so includes a reference to
> Fl_XFont_On_Demand::value(), and this is not exported from libfltk.so.
>
> Here's a small patch:

...

> The short form: add FL_EXPORT in line 117 of FL/x.H.
>

> Richard, can you please try the above patch with dynamic linking? This
> would help to verify the problem so that we know this is the correct
> fix.
>
> But before you do this, please try what happens if you revert the order
> of the fltk libs as Ian suggested. This should be done anyway, but I
> don't think that it will help here. So please do two tests and report
> the outcome:
>
> (1) reorder libs so that libfltk_gl is before libfltk (both static and
> shared builds)
>

> Done. The ordering of the libs in the link as above has no effect and I
> still get the error message.
>

> I assume this will give the same error in the shared build.
>

> True

>
> (2) Apply the patch above, and link shared again.
>
> I assume this will work. Hopefully.
>

> True. The patch worked.

Thanks for confirmation.

> The order of the libs in the link has no
> effect whatsoever with gcc; I tried both '-lfltk -lfltk_gl' and
> '-lfltk_gl -lfltk' and both link correctly. It has been many years now
> that the ordering of the libs on the command line is irrelevant with
> gcc. Granted that was critical in the early days, but now it seems that
> the linker finds the proper ordering by itself. I may be wrong...

I don't know if this is still a problem with recent gcc. Sometimes we
still get reports about this, and reordering the libraries in the linker
command seemed to work (often). However I would only expect such a
dependency on library order for static builds, since if you link a
shared library, all symbols in that library will be available.

With static linking it is different: only symbols referenced before the
object library is "seen" would be used, so a backwards reference from a
later library would not resolve. At least hat's how it was (IIRC), but
maybe things have changed.

[MacArthur, Ian (Selex ES, UK)]

> I don't know if this is still a problem with recent gcc. Sometimes we
> still get reports about this, and reordering the libraries in the
> linker
> command seemed to work (often).

There are a great many gcc/ld combinations extant in the wild for which link order is significant, so we should never assume that is no longer the case.

Also, note that it's a common pattern, so many other compiler/linker combinations exhibit this behaviour too (though IIRC the MS tools generally resolve dependencies recursively, many other do not.)

[jiangq...@gmail.com]

Regarding the X11 library to be used for FLTK1.3.3
I have a program to be installed into the super computer on our campus.
The earlier version of X11 libraries, 1.5.0-4.el6.i686  works for the fltk1.3.3.
But the 1.6.0-6.el6 failed to work.

Our systems are moving to the newest 64 bit X11 libs. Has anyone on this list figure out how to install fltk1.3.3 using the newest X11 libraries from Redhad RHEL6 or RHEL7?
say:    libX11-1.6.0-6.el6.x86_64
in our newest environment in the supercomputer.

Thanks.


Qiu-Xing

[Edzard Egberts]

> But the 1.6.0-6.el6 failed to work.

What does this mean in detail?

> Our systems are moving to the newest 64 bit X11 libs. Has anyone on this
> list figure out how to install fltk1.3.3 using the newest X11 libraries
> from Redhad RHEL6 or RHEL7?
> say: libX11-1.6.0-6.el6.x86_64
> in our newest environment in the supercomputer.

I'm using CentOS 6.8 (final) with libX11-1.6.3-2.el6 (X86_64) and there
never was a problem to use fltk 1.3.3 with X11, also regarding to former
updates. Did you try to rebuild your FLTK (configure/make) on the
supercomputer, to be sure to use the current libraries?