| [ 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 ]
|
| |