STR #3497

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3497

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:2 - Specific to an operating system
Subsystem:Build Files
Summary:fltk-config - support cross compile
Created By:alonbl
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 alonbl
09:41 Oct 07, 2018
#2 alonbl
22:36 Oct 07, 2018
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 alonbl
13:54 Oct 06, 2018

It would be nice if fltk-config will support cross compile.

At minimum ROOT environment variable should be supported to expand cflags/ldflags with this ROOT.
For example, instead of -L/usr/lib64/fltk expand -L/cross-compile-prefix/usr/lib/lib64/fltk

This is the blocker for cross compile with fltk in Gentoo.

Maybe it is time to consider pkg-config support... :)

#2 AlbrechtS
17:07 Oct 06, 2018
Thanks for the report, but please be a little more specific. I know I can cross-compile in two situations:

(1) under Cygwin with the MinGW-w64 cross tools
(2) under Linux (Ubuntu) with the MinGW{32/64} toolchain.

Both are handled with --host=target-triple and it works.

Other than that, if your configuration does not work, we'd need more specific information what exactly you want to do (command line) and what fails. TIA.

Even better: we like patches ;-)

But even with a patch we need a test case so we can verify the situation with and w/o the patch.

That said, FLTK 1.3 is end of life and doesn't get further development. Development of new features is done in FLTK 1.4.

Other than that, did you try the CMake build? In CMake you can write your own toolchain file and FLTK is known to build in cross compilation environments with CMake.

What would "pkg-config support" help with cross-compilation? Or was this just an unrelated question/suggestion?
#3 AlbrechtS
17:09 Oct 06, 2018
Oh, sorry, I may have mis-read your request. You meant to use fltk-config to cross-compile your application?

If yes, please be concrete and give an example what you want to achieve, what the expected result would be, and what the current result is.

#4 AlbrechtS
17:11 Oct 06, 2018
Hmm, and now the 'pkg-config' part makes more sense as well. Do you mean we should output pkg-config files instead or additionally to fltk-config?  
#5 alonbl
21:29 Oct 06, 2018

Yes, the problem is cross compile *using* the library, not the library itself :)

pkg-config is the standard method of querying package flags, is there a reason you use proprietary mechanism instead of pkg-config?

When adding pkg-config, to keep backward compatibility the fltk-config should remain but if possible delegate call to pkg-config.

I will create a patch as minimum for the fltk-config.

#6 AlbrechtS
04:24 Oct 07, 2018
The reasons we're not using pkg-config (yet) are history and compatibility.

FLTK is very conservative in using other software to avoid dependencies and compiler features (C++0x or later, STL, ...). You may take a look at our CMP (Configuration Management Plan) [1] if you're interested in details, but this is also a little outdated (will be fixed soon). FLTK is designed to be compiled on very old and restricted systems (for instance embedded systems, though in this case you'd probably use cross compilation anyway).

A patch would be very much appreciated, but please make sure that there's a fallback in case pkg-config is not available on the build (target) system. See also discussion of STR #3473 [2].


#7 alonbl
04:33 Oct 07, 2018

I will not perform migration to pkg-config, I will do the minimum within the scope of the current config script.

However, even if you think that you want to support old systems that for some reasons do not have pkg-config and have no override of CFLAGS and LDFLAGS, then you should at least provide pkg-config in addition to the proprietary method.

Supporting pkg-config will make integration much easier for cmake, autotools and other systems with or without cross compile.

I will probably open a new bug for this to focus discussion for immediate changes and future ones.

#8 alonbl
09:42 Oct 07, 2018
see attachment#3497  
#9 alonbl
09:43 Oct 07, 2018
See patch at[1] which is working for me.
#10 AlbrechtS
13:22 Oct 07, 2018
Thanks for the patch, I think I understand what it's doing.

But can you please give a concrete example how you would be using it?

I imagine (in bash syntax, likely NOT correct):

$ export SYSROOT=x86_64-mingw32-xxx
$ fltk-config --compile ...

I'd like to know what you are doing, why it doesn't work, and what the expected behavior would be. Example logs (before and after the patch) would be helpful to decide.

Also, how well-defined is the usage of SYSROOT? I mean, if we added this to our fltk-config script as you suggest and anybody had SYSROOT defined for some (other) reason, this would unexpectedly change the behavior of fltk-config.

Sorry if these questions sound stupid, I'm just hesitating and need more info. Links to docs appreciated as well.
#11 alonbl
21:59 Oct 07, 2018
The focus is on packages that use the script using --cflags and --ldflags and build their sources with these flags, although as far as I can see the --compile is also working.

For example, a package that uses autoconf and calling fltk-config will be configured this way:

SYSROOT=/usr/arm-unknown-linux-gnueabi ./configure \
    --host=arm-unknown-linux-gnueabi \
    --enable-fltk \

In this case the autoconf script should use proprietary fltk-config, invoke and parse the content.

Having you support pkg-config, the notation would be:

PKG_CONFIG_SYSROOT_DIR=/usr/arm-unknown-linux-gnueabi ./configure \
    --host=arm-unknown-linux-gnueabi \

And the autoconf would have used the standard notation of pkg.m4:


These macros would get as input from environment:
1. PKG_CONFIG - the pkg-config executable
2. FLTK_CFLAGS - override CFLAGS
And output:
1. FLTK_CFLAGS - the CFLAGS for the library
2. FLTK_LDFLAGS - the LDFLAGS for the library
#12 alonbl
22:38 Oct 07, 2018
A new version[1], I used the '``' operator instead of '$()' to execute subshell to be consistent with the rest of the script.

#13 alonbl
03:32 Oct 10, 2018
Do you need any more information?
#14 AlbrechtS
16:45 Oct 10, 2018
No, thanks, I don't think that I need more information currently. I'm busy with other things though, so please don't hold your breath.

I may need other information later, or another dev may chime in and ask for more info...
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2020 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.