Package Details: mingw-w64-fltk 1.3.9-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-fltk.git (read-only, click to copy)
Package Base: mingw-w64-fltk
Description: Graphical user interface toolkit for X (mingw-w64)
Upstream URL: http://www.fltk.org/
Licenses: custom:LGPL
Submitter: jpcima
Maintainer: jpcima (manuelino)
Last Packager: manuelino
Votes: 0
Popularity: 0.000000
First Submitted: 2017-07-04 01:41 (UTC)
Last Updated: 2024-02-11 11:12 (UTC)

Latest Comments

1 2 Next › Last »

MarsSeed commented on 2023-08-08 13:42 (UTC)

Thank you.

manuelino commented on 2023-08-08 12:54 (UTC)

@MarsSeed Done.

MarsSeed commented on 2023-08-08 12:36 (UTC) (edited on 2023-08-08 12:37 (UTC) by MarsSeed)

I haven't tested it, but for Linux builds, all applications in Arch repo uses the optimized libjpeg-turbo implementation, including fltk.

Also, on AUR, all other mingw-w64 packages depend on mingw-w64-libjpeg-turbo apart from this, and an orphan package from 2017 (mingw-w64-irrlicht).

It seems that basically only libjpeg-turbo is used in the real world by all dependents, so that is what gets battle-tested and bugfixed, not the unoptimized reference implementation, which is hardly used at all by anything.

manuelino commented on 2023-08-08 11:10 (UTC)

@MarsSeed I have switched libraries and tested that the package builds, and used it to build a test application. However, I am not able to fully exercise JPEG capabilities of FLTK to ensure that the change does not bring unwanted side effects.

Have you already tested a custom build depending on libjpeg-turbo or could you do some tests if I shared the updated PKGBUILD outside the AUR before pushing?

MarsSeed commented on 2023-07-27 00:17 (UTC) (edited on 2023-07-27 00:23 (UTC) by MarsSeed)

Please make this depend on mingw-w64-libjpeg-turbo, not on the unoptimized reference implementation mingw-w64-libjpeg.

manuelino commented on 2020-02-19 20:04 (UTC)

I've updated the PKGBUILD so that the package currently builds and works with AUR helpers which expect the correct architecture in the filename.

It should be noted that the DSOFLAGS variable, which I used to pass flags to the shared library link command, despite being placed in the configure scripts within LDFLAGS & co, is never mentioned within FLTK documentation, or at least I could not find any trace of it. Maybe it's an oversight or maybe I've just done a kludge.

jpcima commented on 2020-02-18 09:26 (UTC)

@manuelino Thanks, I am unable to look into this now and fix it unfortunately. I add you to the maintainers list, please update the package as you wish.

manuelino commented on 2020-02-14 21:32 (UTC)

After having re-read my comment after some relax I noticed the logical error... mingw-w64-configure cannot have an impact on LDFLAGS if that variable is not used by FLTK. Also, they have removed -lspp from LDFLAGS, but -fstack-protector is still there.

The problem is simply that LDFLAGS is used by FLTK when building executables but not when building DSO's. Simply alias DSOFLAGS to be equal to LDFLAGS and everything is fine.

manuelino commented on 2020-02-13 17:55 (UTC)

I am experiencing problems while building this package. Two issues, to be precise.

The first one is that the arch variable used to iterate over architectures conflicts with the arch entry within the PKGBUILD, causing the final archive to have x86_64 in its filename rather than any. The package builds, but if installed via an AUR helper such as Yay it complains that the package cannot be found due to the wrong filename.

The second issue is that mingw-w64-configure has dropped -lssp from LDFLAGS. However, FLTK does not use LDFLAGS when building shared libraries, instead it uses a custom DSOFLAGS variable, which is never populated with -fstack-protector. So the shared FLTK libraries are never linked against libssp and linking fails.

I've managed to edit the PKGBUILD to make it work. It can be found here:

https://pastebin.com/TXz42H5w

jpcima commented on 2018-02-07 17:49 (UTC)

@Martchus It's fixed.

1 2 Next › Last »