Nicolas Boulenguez wrote: > The package failed to build on several GNUstep architectures.
The other failures are not GNUstep-specific, AFAICS (except on sparc)? > One still fails, see > https://buildd.debian.org/fetch.cgi?pkg=oolite&arch=sparc&ver=1.75-1&stamp=1298935457&file=log&as=raw For this, you need to preprocess the source on a sparc machine to figure out what's going on. A more burdensome approach is to examine carefully the source. > More seriously, Yavor Doganov <[email protected]> is CCed since he may > want to provide a rational explanation about endian.h being included > indirectly by #include <math.h> but not by #import <math.h> (maybe > CCing to [email protected] if the answer is of general public > interest). AFAIK <endian.h> is not included by <math.h>. Most probably it is included by <sys/types.h>, which itself is indirectly included by another dependency (like png or zlib). The reason to avoid using #import for C headers is precisely this -- it is very difficult to track down the problem, and it may come at any time when any of the involved headers changes. C headers are simply not designed to work with #import. Usually, many include other C headers, sometimes conditionally via defines, sometimes machine-specific. Some headers are designed to work differently if they've already been included once. When you #import parts which are #include'd from other C headers, you may end up missing some bits eventually and would be very confused why it happens. Unfortunately, many Objective-C tutorials erroneously teach people to use #import freely, which is why a lot of programmers get into the bad habit of doing it. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
