| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3409
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 2 - Specific to an operating system |
Subsystem: | MacOS |
Summary: | libpng |
Version: | 1.3.4 |
Created By: | w1hkj |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | 46cbc31de25b4579801cc783a01e9ce1be4c53a6 |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | w1hkj 14:18 Sep 28, 2017 |
| fltk configure fails to correctly identify libpng 1.2.6 on OS X. results in some applications being built with fltk_png @ versions 1.5.0 lib and 1.2.6 headers. Work around is to delete all libpng from system and symbolically link fltk_png to png so that application configure uses same png libs and headers as fltk library. | |
|
#2 | manolo 05:33 Oct 05, 2017 |
| could you try ./configure --disable-localpng that should use only the FLTK version of libpng? | |
|
#3 | manolo 05:44 Oct 05, 2017 |
| On Mac OS X, I see that configure always uses the FLTK version of libpng : Image Libraries: JPEG=Builtin PNG=Builtin The result is that FLTK source files are compiled with -I../png so that #include <png.h> hits the FLTK version of libpng and link contains -L../lib -lfltk_png to use also the FLTK version of libpng.
When building an application, if these -I and -L compiler and linker flags are used, the application should also only hit the FLTK version of libpng.
Therefore, please give more details of how you build FLTK and what compilation and link commands you use to get mixed versions of libpng. | |
|
#4 | w1hkj 05:45 Oct 05, 2017 |
| That will not solve the problem. Fltk is already building with the internal png library. The application which uses the fltk UI does correctly recognize the external png lib/headers. That is what causes the conflict when executing the application binary. | |
|
#5 | w1hkj 05:54 Oct 05, 2017 |
| Good morning ... I think we are playing tag ... sorry about that.
The application is fldigi, http://www.w1hkj.com/files/fldigi/fldigi-4.0.10.tar.gz
which uses m4 scripts/configure.ac; configure to discover development headers and libs for various dependencies, including jpeg, png and z. The png lib and headers are version 1.2.6 (current release). Fltk internal is 1.5.0, an older version. I think that fltk configure.ac --> configure needs to be changed so that the fltk source correctly finds the installed 1.2.6 | |
|
#6 | matt 05:29 Jan 20, 2023 |
| Is this the case in 1.4 master? We did change quite a bit in the configuration and build system in the last 6 years. | |
|
#7 | AlbrechtS 05:49 Jan 20, 2023 |
| I don't think that the described problem is still an issue, but it's hard to understand which circumstances led to the OP's problem.
I can tell that we changed building the bundled libs to use their own "prefix" for function names. This makes it possible to use one version of libpng in FLTK's internals (for images) and using another - incompatible - libpng in the application or in any shared system libs.
This does even work for loading shared libraries dynamically at runtime. These "prefixed" bundled libraries solved all kinds of problems with incompatible image libraries.
Therefore I believe that this STR is no longer relevant (i.e. resolved) in FLTK 1.4.0, but I can be wrong if the OP had another issue. Finding the "correct" libs installed on the system should no longer be an issue. It doesn't matter if we "find" a certain libpng version, it's more about building FLTK with either the system or the bundled version, and the latter is definitely fixed.
I suggest to close this STR if the OP (w1hkj) doesn't chime in and explains why this STR is still relevant. | |
|
#8 | AlbrechtS 05:55 Jan 20, 2023 |
| BTW, there is no such thing like "libpng 1.2.6 on OS X" (or today macOS). This depends on additionally installed libraries by the user, using one of the special package systems like homebrew and others. Hence I don't think that we can easily change configure to find "the right" library.
The solution to this STR is to use the bundled libs on macOS which is now the default anyway and should be compatible with all system libs and applications using "other" libpng versions. | |
|
#9 | AlbrechtS 06:18 Jan 20, 2023 |
| Fixed in Git repository.
The given "fix commit" is when the library prefixing was done.
Note: the OP (w1hkj) is unreachable (mail bounced).
If this is still an issue, please open a GitHub issue. | |
[ Return to Bugs & Features ]
|
| |