I'm trying to compile NCSA Mosaic-2.7 CK 13 as 32-bit application on macOS 10.7.5 (Lion for short).
Its OpenMotif 2.1.31 compatible version of 32-bit binary works quite fine on Lion when installed as /Applications/Mosaic-CK.app
so I assume I should be able to compile it on my Mac too. When I do make osx
as given in the INSTALL file or in shortened form here, it compiles lots of source files (such as HTFile.c
HTFormat.c
HTFWriter.c
HTFTP.c
HTInit.c
HTTP.c
Xmx.c
HTML.c
HTMLwidgets.c
gui.c
gui-dialogs.c
newsrc.c
hotlist.c
img.c
xpmread.c
gifread.c
mailto.c
system.c
strtools.c
among others) for about a minute then it stops at the /src/readPNG.c
and says:
readPNG.c: In function ‘ReadPNG’:
readPNG.c:136:42: error: invalid application of ‘sizeof’ to incomplete type ‘png_info {aka struct png_info_def}’
info_ptr = (png_info *)malloc(sizeof(png_info));
^
readPNG.c:143:23: error: dereferencing pointer to incomplete type ‘png_struct {aka struct png_struct_def}’
if (setjmp(png_ptr->jmpbuf)) {
The libpng installation on my Lion might be causing this. On my Lion, the libpng is installed as a separate folder like: /usr/local/libpng-1.6.15
it's not installed as mixed into the /usr/local/lib
and /usr/local/include
The INSTALL instructions under the heading make osx
says:
Install libz, libpng and libjpeg to /usr/local(/lib) The .a's, not the dynamic/shlibs! IF YOU DON'T HAVE THEM, YOU NEED TO BUILD THEM!
If that is the issue causing the compile problem, then how to make my /usr/local/libpng-1.6.15
installation compatible with the /usr/local(/lib)
?
If not, then how to get around the error invalid application of ‘sizeof’ to incomplete type
?
My system and the related environment variables:
/opt
directory is present./usr/local
in their respective separate folders.GCC=/usr/local/gcc-5.0.0
(GCC-4.6, 3.3 and 10.0 are present, too. I've tried compiling with them, no change in situation)CFLAGS=-Wall -arch x86_64
CPPFLAGS=-I/usr/local/openssl-1.1.0j/include -I/usr/local/gmp-6.1.2/include -I/usr/local/readline-8.1/include
LDFLAGS= -mmacosx-version-min=10.7
LIBPNG=/usr/local/libpng-1.6.15
ZLIB=/usr/local/zlib-1.2.11
LIBJPEG=/usr/local/libjpeg-9c
XCODE=/Applications/Xcode-4.6.2.app/Contents/Developer
(PATH=$XCODE/usr/bin:$PATH
line is present at ~/.bash_profile
)Long story short, the file readPNG.c
doesn't have a definition of libpng structs, just a declaration of the name (from png.h
) without defining the structure (from pngstruct.h
and pnginfo.h
)
I would blame it on the mix of Mosaic-2.7 CK 13
that is written for libpng 1.2.35 released on April 2009, and your version of libpng 1.6.15 released on November 2014.
The definition of png_struct
and png_info
were moved out of png.h
at version 1.5.0beta01.
png_struct_def
, png_info_struct
png_struct_def
, png_info_def
In addition you will have more problems from this mix of versions, at Mosaic-2.7 CK 13
the file readPNG.c
have the following code (snippets of the relevant lines only):
/* ...
* ...
*/
png_struct *png_ptr;
png_info *info_ptr;
/* ...
* ...
*/
png_ptr = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);
if(!png_ptr)
return 0;
info_ptr = (png_info *)malloc(sizeof(png_info));
if(!info_ptr) {
png_destroy_read_struct(&png_ptr, NULL, NULL);
return 0;
}
/* Establish the setjmp return context for png_error to use. */
if (setjmp(png_ptr->jmpbuf)) {
/* ...
* ...
*/
From libpng changelog:
Version 1.4.0beta103 [November 21, 2009] Make the 'png_jmpbuf' macro expand to a call that records the correct longjmp function as well as returning a pointer to the setjmp jmp_buf buffer, and marked direct access to jmpbuf 'deprecated'. (John Bowler)
Version 1.5.0beta09 [February 19, 2010] Changed the name of png_ptr->jmpbuf to png_ptr->png_jmpbuf in pngstruct.h
Version 1.5.3beta04 [April 27, 2011] Changed png_struct jmp_buf member name from png_jmpbuf to tmp_jmpbuf to avoid a possible clash with the png_jmpbuf macro on some platforms.
So at readPNG.c
line 143 should be changed from if (setjmp(png_ptr->jmpbuf)) {
to if (setjmp(png_jmpbuf(png_ptr))) {
Does this guarantee you won't have any more errors? definitely not!
I don't know what your application is and can't advise you to use an old library version with known vulnerabilities, but by manually patching the code of Mosaic-2.7 CK 13
you may find yourself in a very long battle.