FLTK logo

STR #3409

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   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 | 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:

Receive EMails Don't Receive EMails

Trouble Report Files:

No files


Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

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