| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2833
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Build Files |
|---|
| Summary: | fltk-3 tries to compile local PNG lib even if system lib is selected |
|---|
| Version: | 3.0 |
|---|
| Created By: | ianmacarthur |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | ianmacarthur
14:19 Apr 30, 2012 |
| Fltk-3 attempts to build the local PNG files even if configure selects the system PNG libs instead.
However, this usually fails, since the local PNG lib is newer than most distros (including OSX) are currently shipping, and since the system header files are found before the local PNG header files, version mis-match occurs.
I have seen this fail on OSX and Linux (and maybe mingw too, not certain) and appears to be a "feature" of the restructured build hierarchy, perhaps.
Anyway, here's a snapshot from OSX (though other hosts are similar...)
First, see that we configure with the SYSTEM image libs:
Configuration Summary
-------------------------------------------------------------------------
Directories: prefix=/usr/local
bindir=${exec_prefix}/bin
datadir=${datarootdir}
datarootdir=${prefix}/share
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
mandir=${datarootdir}/man
Graphics: Quartz
Image Libraries: JPEG=System
PNG=System
ZLIB=System
Large Files: YES
OpenGL: YES
Threads: YES
configure: creating ./config.status
config.status: creating makeinclude
config.status: creating fltk.list
config.status: creating fltk3-config
config.status: creating fltk.spec
config.status: creating include/fltk3/Makefile
config.status: creating include/config.h
Now note that during the build, we attempt to build libpng anyway, but it fails since the system headers do not match the local png source files...
Compiling fltk3images/PNMImage.cxx...
/usr/bin/ar cr ../lib/libfltk3images.a ...
Compiling fltk3png/png.c...
fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory
fltk3png/png.c:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘Your_png_h_is_not_version_1_5_10’
fltk3png/png.c:559: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PNGAPI’
fltk3png/png.c:649: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PNGAPI’
fltk3png/png.c:680: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PNGAPI’
fltk3png/png.c:687: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PNGAPI’
fltk3png/png.c:695: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PNGAPI’
fltk3png/png.c:762: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘PNGAPI’
make[1]: *** [fltk3png/png.o] Error 1
make: *** [all] Error 1
immpcx:fltk-3-syslibs ian$ | |
| |
| #2 | ianmacarthur
14:22 Apr 30, 2012 |
| As a rider to this, I find that with judicious tweaking of the include paths in makeinclude I can get this to build OK, so that might be a feasible workaround.
Though I do wonder why it is building the local libs at all if the system ones are selected (note that it also builds the local zlib and jpeg, though they seem less "fragile" than the PNG build is.) | |
[ Return to Bugs & Features ]
|
| |
