Fatal Syntax Errors Unique to XCode Compile

Question

Level 1

0 points

Fatal Syntax Errors Unique to XCode Compile

I am attempting to bring a Unix library into an XCode project for iPad and compile it. This Unix library compiles for i386 without any problems when I use gcc from Terminal, which is v4.2. However, when I attempt to compile those same sources from within the XCode project, I receive hundreds of fatal syntax errors, even though I it is still compiling to i386, and it is still using GCC 4.2. Here is an example declaration where it gives an error:

The Code:
int memcmp(const void *, const void *, size_t);

The error:
Expected declaration specifiers or '...' before '(' token

I must admit I am just now reading my introduction to Objective-C, so it is possible that there is a syntax error there according to some strict guidelines. The above code is actually C, but I did not worry about this because I was not expecting to extensively modify this library.

How is the XCode compile so different from using Apple's built-in GCC 4.2 that I receive hundreds of fatal syntax errors from within XCode, but it compiles with only a few warnings from the command line?

iPhone OS 3.1.3

Posted on Oct 13, 2010 6:55 AM

Reply

Answer 1

kienjakenobi Author

Level 1

0 points

Oct 13, 2010 7:20 AM in response to kienjakenobi

This idea just came to me, and it seems to have worked.

If I right click on one of the .c source files and change the File Type from "sourcecode.c.c" to "sourcecode.c," the syntax errors go away.

It seems the C code is fine, it was just being interpreted as something other than normal ANSI C.

What does the sourcecode.c.c refer to?

Reply

Answer 2

kienjakenobi Author

Level 1

0 points

Oct 13, 2010 7:29 AM in response to kienjakenobi

Never-mind that. Switching the file type to .c instead of .c.c made me think it was working because it gave nothing but a few warnings, but it is not actually doing anything.

On closer inspection, I saw it gives these warnings: "No rule to process file /dir/dir/file.c for architecture i386"

This is obviously not going in the right direction.

Reply

Answer 3

etresoft

Level 8

47,580 points

Oct 13, 2010 7:47 AM in response to kienjakenobi

The Xcode build system is optimized for MacOS and iOS platforms. If you have an existing, cross-platform library, it would be better to use an external build system (i.e. Makefile) for this library. Otherwise, you will have a lot of work to track down each and every build setting adjust it. You might also try to create a new project. What template did you start with? It would be best to start with the iOS "STL C++ Library", even if you aren't using C++. That template would be more likely to have default settings more compatible to what you would find on the command line.

Reply

Answer 4

kienjakenobi Author

Level 1

0 points

Oct 13, 2010 3:14 PM in response to kienjakenobi

Clearly, I do not completely understand what the Makefile compile system is doing through Makefiles that I have not covered in the XCode project, but could this actually be causing syntax errors? I dod not see how build settings should be causing all these syntax errors.

The hundreds of errors it gives me are all very simple syntax violation errors. It is giving the sort of errors that I should see if there were an unclosed parenthesis or something similar in the code.

However, I did not actually start this project from a template in XCode. I used convertmake to gather data on the gnu configure and make steps, which automatically created an XCode project for me.

This was a shortcut, but it does not seem to be working, unfortunately. I think I am just going to have to fiddle with the GCC CFLAGS until I can get something that will compile for the armv7 architecture, and then just link directly to it from my iPad project.

Reply

Answer 5

etresoft

Level 8

47,580 points

Oct 13, 2010 4:39 PM in response to kienjakenobi

kienjakenobi wrote:
Clearly, I do not completely understand what the Makefile compile system is doing through Makefiles that I have not covered in the XCode project, but could this actually be causing syntax errors? I dod not see how build settings should be causing all these syntax errors.

The makefile probably uses gcc or g++ to build files with all the default settings. Xcode uses non-default settings so it can do things like target 10.5 and iOS.

However, I did not actually start this project from a template in XCode. I used convertmake to gather data on the gnu configure and make steps, which automatically created an XCode project for me.

Ahhh... Code form 2006 strikes again.

This was a shortcut, but it does not seem to be working, unfortunately. I think I am just going to have to fiddle with the GCC CFLAGS until I can get something that will compile for the armv7 architecture, and then just link directly to it from my iPad project.

Why not create a makefile-based project and be done with it. That is what it is there for. Through Xcode you can change the flags you need to target iOS. Create a C++ hello world library for the Mac. Then do the same for iOS. Review the differences and apply those changes to your makefile based project.

Reply

Answer 6

kienjakenobi Author

Level 1

0 points

Oct 13, 2010 8:46 PM in response to etresoft

Many thanks for your input, etresoft.

As of my last post, my plan was to build the libraries on my own using configure+make from a terminal and then to link the finished binaries from my iPad project.

I think I understand that you suggested that I actually create an XCode project that is makefile based. That is to say, it uses an external build system. I think I like that idea, but I did not know this would work. I followed the "Building Makefile Projects With Xcode" section of the Porting Unix to Mac XCode Documentation.

Here is the bash script I used to do the configure before I brought the project into the XCode external build system project:

BEGIN SCRIPT
#!/bin/bash
#script to configure Unix software for iPhone

export CONFIG_SHELL=/bin/bash

topDir=$(cd $(dirname $0) && pwd)

export DEVROOT="/Developer/Platforms/iPhoneOS.platform/Developer"

export SDKROOT="$DEVROOT/SDKs/iPhoneOS3.2.sdk"

export CPPFLAGS="-I$SDKROOT/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I$SDKROOT/usr/include/"

export CFLAGS="$CPPFLAGS -arch armv7 -pipe -no-cpp-precomp -isysroot $SDKROOT"

export CPP="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp $CPPFLAGS"

export CC="$DEVROOT/usr/bin/gcc-4.2"

export LD="$DEVROOT/usr/bin/ld"

LIBPATH_static="zlib.a"
LIBNAME_static="basename $LIBPATH_static"

$topDir/configure --static
END SCRIPT

Doing that configure before I followed the documentation's instructions on created the project did the trick. XCode is now capable of building the static library. In my case, this was zlib. Both the configuration and the compiling occurred without error, so I believe the library was created correctly, but I am not yet certain, as I have not yet had the chance to test it.

Message was edited by: kienjakenobi

Message was edited by: kienjakenobi

Message was edited by: kienjakenobi

Reply

Answer 7

etresoft

Level 8

47,580 points

Oct 14, 2010 8:56 AM in response to kienjakenobi

kienjakenobi wrote:
I think I understand that you suggested that I actually create an XCode project that is makefile based. That is to say, it uses an external build system. I think I like that idea, but I did not know this would work. I followed the "Building Makefile Projects With Xcode" section of the Porting Unix to Mac XCode Documentation.

Apparently the template for External Build Tool is only for MacOS X. However, you could still use it for iOS since it doesn't have any platform information. You would just have to provide all the appropriate values in your Makefile or environment. It seems like you know what those are.

XCode is now capable of building the static library. In my case, this was zlib.

Zlib is already part of iOS. You don't have to build it.

Reply

Answer 8

kienjakenobi Author

Level 1

0 points

Oct 14, 2010 10:37 AM in response to etresoft

Yes, the External Build System template was listed under Mac OSX. However, as you said, it does not create any platform-specific settings, so it integrated without any problem into my armv7-specific iOS project.

I did not realize that zlib is already there. I went through the files listed in /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/inclu de/, and now I see the zlib.h.

However, this was more of a learning experience for me. I will need to compile five other unix libraries for iOS that are not inlcuded with iOS. Hopefully I will be able to use the above method without many changes to achieve the same success with these other libraries.

At the moment, I am having difficulty compiling libpng. libpng does not appear to like Apple's custom stdio.h header file.

Reply

Answer 9

etresoft

Level 8

47,580 points

Oct 14, 2010 12:05 PM in response to kienjakenobi

kienjakenobi wrote:
At the moment, I am having difficulty compiling libpng. libpng does not appear to like Apple's custom stdio.h header file.

What errors are you getting? I'm pretty sure I've build this library before, although not for iOS. Building for iOS shouldn't be much different than any cross-platform build, such as when building 32-bit on a 64-bit machine.

I tried it myself and couldn't get the configure script to do it all. Those things never work when you need them to. I had to hack up the Makefile and libtool file. Here is a patch file:

diff -crB libpng-1.2.44/Makefile libpng-1.2.44.iOS/Makefile
* libpng-1.2.44/Makefile 2010-10-14 14:57:16.000000000 -0400
--- libpng-1.2.44.iOS/Makefile 2010-10-14 14:50:06.000000000 -0400
*************
* 171,180 **
 AUTOHEADER = ${SHELL} /Users/jdaniel/Downloads/libpng-1.2.44/missing --run autoheader
 AUTOMAKE = ${SHELL} /Users/jdaniel/Downloads/libpng-1.2.44/missing --run automake-1.11
 AWK = awk
! CC = gcc
 CCDEPMODE = depmode=gcc3
! CFLAGS = -g -O2
! CPP = gcc -E
 CPPFLAGS = 
 CYGPATH_W = echo
 DEFS = -DHAVECONFIGH
--- 171,180 ----
 AUTOHEADER = ${SHELL} /Users/jdaniel/Downloads/libpng-1.2.44/missing --run autoheader
 AUTOMAKE = ${SHELL} /Users/jdaniel/Downloads/libpng-1.2.44/missing --run automake-1.11
 AWK = awk
! CC = /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc
 CCDEPMODE = depmode=gcc3
! CFLAGS = -g -O2 -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -arch armv7
! CPP = /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp -E
 CPPFLAGS = 
 CYGPATH_W = echo
 DEFS = -DHAVECONFIGH
*************
* 194,200 **
 INSTALL_PROGRAM = ${INSTALL}
 INSTALL_SCRIPT = ${INSTALL}
 INSTALLSTRIPPROGRAM = $(install_sh) -c -s
! LD = /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld
 LDFLAGS = 
 LIBOBJS = 
 LIBPNG_DEFINES = -DPNGCONFIGURELIBPNG 
--- 194,200 ----
 INSTALL_PROGRAM = ${INSTALL}
 INSTALL_SCRIPT = ${INSTALL}
 INSTALLSTRIPPROGRAM = $(install_sh) -c -s
! LD = /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld
 LDFLAGS = 
 LIBOBJS = 
 LIBPNG_DEFINES = -DPNGCONFIGURELIBPNG 
diff -crB libpng-1.2.44/config.log libpng-1.2.44.iOS/config.log
* libpng-1.2.44/config.log 2010-10-14 14:57:16.000000000 -0400
--- libpng-1.2.44.iOS/config.log 2010-10-14 14:48:08.000000000 -0400
*************
* 30,37 **
 Processor type: i486 (Intel 80486)
 Processors active: 0 1
 Primary memory available: 4.00 gigabytes
! Default processor set: 90 tasks, 370 threads, 2 processors
! Load average: 0.28, Mach factor: 1.71
 /bin/machine = unknown
 /usr/bin/oslevel = unknown
 /bin/universe = unknown
--- 30,37 ----
 Processor type: i486 (Intel 80486)
 Processors active: 0 1
 Primary memory available: 4.00 gigabytes
! Default processor set: 90 tasks, 374 threads, 2 processors
! Load average: 0.38, Mach factor: 1.60
 /bin/machine = unknown
 /usr/bin/oslevel = unknown
 /bin/universe = unknown
diff -crB libpng-1.2.44/libtool libpng-1.2.44.iOS/libtool
* libpng-1.2.44/libtool 2010-10-14 14:57:16.000000000 -0400
--- libpng-1.2.44.iOS/libtool 2010-10-14 14:55:40.000000000 -0400
*************
* 240,249 **
 hardcodeintolibs=no
 
 # Compile-time system search path for libraries.
! syslib_search_path_spec="/usr/lib/gcc/i686-apple-darwin10/4.2.1/x8664 /usr/lib/i686-apple-darwin10/4.2.1 /usr/lib /usr/local/lib"
 
 # Run-time system search path for libraries.
! syslib_dlsearch_pathspec="/usr/local/lib /lib /usr/lib"
 
 # Whether dlopen is supported.
 dlopen_support=unknown
--- 240,249 ----
 hardcodeintolibs=no
 
 # Compile-time system search path for libraries.
! syslib_search_pathspec="/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib"
 
 # Run-time system search path for libraries.
! syslib_dlsearch_pathspec="/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib"
 
 # Whether dlopen is supported.
 dlopen_support=unknown
*************
* 260,272 **
 
 
 # The linker used to build libraries.
! LD="/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld"
 
 # Commands used to build an old-style archive.
 oldarchivecmds="$AR $AR_FLAGS $oldlib$oldobjs~$RANLIB $oldlib"
 
 # A language specific compiler.
! CC="gcc"
 
 # Is the compiler the GNU compiler?
 with_gcc=yes
--- 260,272 ----
 
 
 # The linker used to build libraries.
! LD="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld"
 
 # Commands used to build an old-style archive.
 oldarchivecmds="$AR $AR_FLAGS $oldlib$oldobjs~$RANLIB $oldlib"
 
 # A language specific compiler.
! CC="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc"
 
 # Is the compiler the GNU compiler?
 with_gcc=yes

It seems to work:

file ./.libs/libpng12.0.dylib


./.libs/libpng12.0.dylib: Mach-O dynamically linked shared library arm

You don't need to create static libraries. Just use the "install nametool" to change the location of the dynamic libraries to @executable_path and include the required libraries inside your application bundle.

Reply

Answer 10

kienjakenobi Author

Level 1

0 points

Oct 14, 2010 6:30 PM in response to kienjakenobi

Many thanks for your willingness to help.

I used this to configure libpng, and it configured without any errors:


#!/bin/bash
# script to configure Unix software for iPhone
export CONFIG_SHELL=/bin/bash
topDir=$(cd $(dirname $0) && pwd)
export DEVROOT="/Developer/Platforms/iPhoneOS.platform/Developer"
export SDKROOT="$DEVROOT/SDKs/iPhoneOS3.2.sdk"
export CPPFLAGS="-I$SDKROOT/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I$SDKROOT/usr/include/"
export CFLAGS="$CPPFLAGS -arch armv7 -pipe -no-cpp-precomp -isysroot $SDKROOT"
export CPP="/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp $CPPFLAGS"
export CC="$DEVROOT/usr/bin/gcc-4.2"
export LD="$DEVROOT/usr/bin/ld"
LIBPATH_static="zlib.a"
LIBNAME_static="basename $LIBPATH_static"
$topDir/configure --host=arm-apple-darwin --disable-shared --enable-static

However, when I do the external build from XCode, it successfully builds several source files, and then I get this error:


/bin/bash ./libtool --tag=CC --mode=compile /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -DHAVECONFIGH -I. -DPNGCONFIGURELIBPNG -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/ -arch armv7 -pipe -no-cpp-precomp -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -MT libpng14_la-pngpread.lo -MD -MP -MF .deps/libpng14_la-pngpread.Tpo -c -o libpng14_la-pngpread.lo `test -f 'pngpread.c' || echo './'`pngpread.c
libtool: compile: /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -DHAVECONFIGH -I. -DPNGCONFIGURELIBPNG -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/ -arch armv7 -pipe -no-cpp-precomp -isysroot /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -MT libpng14_la-pngpread.lo -MD -MP -MF .deps/libpng14_la-pngpread.Tpo -c pngpread.c -o libpng14_la-pngpread.o
mv -f .deps/libpng14_la-pngpread.Tpo .deps/libpng14_la-pngpread.Plo
rm -f libpng.sym libpng.sym.new
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/cpp -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/ -DPNGCONFIGURELIBPNG -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/ -I/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/ -DPNG_BUILDSYMS ./png.h | 
 /usr/bin/sed -n -e 
 's|^.*PNGFUNCTIONEXPORT[ ](['_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789']*).$| |p' 
 -e 's|^.*PNGDATAEXPORT[ ](['_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789']*).$| |p' 
 >libpng.sym.new
In file included from /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/stdio.h:444,
 from ./pngconf.h:302,
 from ./png.h:404:
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/secure/_stdio.h:46: error: syntax error in macro parameter list
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/secure/_stdio.h:53: error: syntax error in macro parameter list

However, I also discovered that the official libpng sources actually come with an XCode project that works using XCode's native build system to compile libpng.a and .dylib for both Mac and iOS. This is useful, but I do still wish I knew why my port of libpng did not work.

Reply

Answer 11

etresoft

Level 8

47,580 points

Oct 14, 2010 7:32 PM in response to kienjakenobi

kienjakenobi wrote:


/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/secure/_stdio.h:46: error: syntax error in macro parameter list
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk/usr/include/secure/_stdio.h:53: error: syntax error in macro parameter list

I got those two errors too, but they don't seem to have any negative impact. Were you able to get the libraries to build?

However, I also discovered that the official libpng sources actually come with an XCode project that works using XCode's native build system to compile libpng.a and .dylib for both Mac and iOS.

I didn't see any iOS target in that project.

This is useful, but I do still wish I knew why my port of libpng did not work.

Try it without the CPPFLAGS and without "-pipe -no-cpp-precomp". I don't think those are required and could be causing problems. Also, I don't think you need static libraries at all. Even if you do want them, you don't need to start with them. Get it working first, then refine it.

I was unable to get the configure script to accept environment variables. Of course, I may be just lazy. I will give a configure script only a couple of tries before I start hacking the makefile.

Reply

Answer 12

kienjakenobi Author

Level 1

0 points

Oct 16, 2010 6:26 AM in response to etresoft

etresoft wrote:

I got those two errors too, but they don't seem to have any negative impact. Were you able to get the libraries to build?

XCode actually says that the build was successful, even though it gives those two errors. I thought XCode was mistaken, because I could not find any libpng.a file. Instead, I was getting libtool files: libpng14.pc and a libpng14.la file. However, I took a closer look at the XCode log and found that it did actually create a libpng14.a file, but it was hidden in a .libs/ folder. I believe the mystery is resolved.

I didn't see any iOS target in that project.

In the libpng-1.4.4 source files, there is a projects folder with an xcode project file that includes targets for Mac OSX 10.5 and 10.6, as well as iOS Device and even iOS Simulator targets.

Try it without the CPPFLAGS and without "-pipe -no-cpp-precomp". I don't think those are required and could be causing problems. Also, I don't think you need static libraries at all. Even if you do want them, you don't need to start with them. Get it working first, then refine it.

Eventually I will certainly need static libraries if I am linking to libpng in my iOS project. The iOS devices do not support dynamic libraries. I could create dynamic libraries for Simulator testing, but they will not run on the device.

I was unable to get the configure script to accept environment variables. Of course, I may be just lazy. I will give a configure script only a couple of tries before I start hacking the makefile.

The script I wrote above seems to work fine for me. I just run it in Terminal and configure picks up on all the environment variables that I exported.

Reply

Answer 13

etresoft

Level 8

47,580 points

Oct 16, 2010 9:51 AM in response to kienjakenobi

kienjakenobi wrote:
In the libpng-1.4.4 source files, there is a projects folder with an xcode project file that includes targets for Mac OSX 10.5 and 10.6, as well as iOS Device and even iOS Simulator targets.

OK. Somehow, I was using 1.2. Sorry about that. I don't know why or how I downloaded that one.

Eventually I will certainly need static libraries if I am linking to libpng in my iOS project. The iOS devices do not support dynamic libraries. I could create dynamic libraries for Simulator testing, but they will not run on the device.

Interesting. I bet they would work fine if you included them in the app bundle and told the executable where to find them. I will have to try that myself and see what happens. It isn't commonly done even on MacOS X and would be the only way to install a dynamic library on iOS. I guess on iOS it wouldn't make that much of a difference anyway.

The script I wrote above seems to work fine for me. I just run it in Terminal and configure picks up on all the environment variables that I exported.

Sorry about the confusion over the libpng version. I think it would be best to stick with the Xcode version. That would be easier to integrate into your own project as a dependency.

Reply

Answer 14

kienjakenobi Author

Level 1

0 points

Oct 17, 2010 7:05 AM in response to etresoft

etresoft wrote:

Interesting. I bet they would work fine if you included them in the app bundle and told the executable where to find them. I will have to try that myself and see what happens. It isn't commonly done even on MacOS X and would be the only way to install a dynamic library on iOS. I guess on iOS it wouldn't make that much of a difference anyway.

I have not tried it, but all of the documentation I have read, as well as everything I have read from other people online indicate that the dynamic libraries simply do not work. I do not know why.

Perhaps they will work, but they are simply not accepted by the Apple iTunes App Review Process? Perhaps they only accept code that becomes part of the main executable?

Sorry about the confusion over the libpng version. I think it would be best to stick with the Xcode version. That would be easier to integrate into your own project as a dependency.

Yes, it is very convenient that libpng provides an XCode version. I will use that for libpng as long as it remains updated, but, as I said earlier, I will also need to port 5 other libraries that certainly do not come with XCode projects, so simpler libraries like zlib and libpng were good practice for the bigger fish.

Thanks for all your help.

Reply