Hello, problems such as this should not result in a switch of the compiler and pulling in the huge apple-gcc42 port. This can be fixed with simpler methods than ruling out clang. See also Clemens' mail in which he recently explained the situation on implicit assumption about the compiler [1].
In this case, the original four errors were all of this type: elp.c:252:1: error: non-void function 'elpLotrsShrink' should return a value [-Wreturn-type] When looking at the reported source location, this is an obvious error in the statement "return;". This can be fixed with a patch by changing this to "return 0;" as the return value of this function is never used anyway. Or just change the function declaration to void. As an alternative, this can be fixed by using CFLAGS to make clang less strict about the problems in this file - in the same way gcc only generates a warning and does not error out for this problem. Anyway, there is definitely no need to use a different compiler or even force building of the apple-gcc42 port. Here are the options: a) Make clang less strict with an option in the Portfile: configure.cflags-append -Wno-return-type b) Do the same as a) but with a patch to the Makefile in the subdirectory to apply it only locally. c) Apply a patch to eliminate this wrong "return;", also submit it upstream. Remember that llvm-gcc42 will most probably also not be available forever and it's already four releases behind the mainline gcc used on other platforms. Rainer [1] http://lists.macosforge.org/pipermail/macports-dev/2012-January/017470.html _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
