On 5/2/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:> Well, I don't quite understand why AC_C_BIGENDIAN and the solution > you're proposing is likely to break other big endian machines (the ones > that don't have __BIG_ENDIAN__). Can you send a patch that addresses > that (i.e. still uses AC_C_BIGENDIAN when it works)?It is not that AC_C_BIGENDIAN does not work. It is that it determines endianness at configure-time as opposed to compile-time. The process for building universal binaries on Mac demands that the distinction be made at compile-time. To enable building universal binaries on Mac in a single pass, the decision has to be deferred to compile-time. My strong suspicion is that testing __BIG_ENDIAN__ at compile-time will work for all relevant unix-like platforms. Even icc supports this. The extra thing we could do is set a preprocessor variable at configure-time that we could use at compile-time to determine whether the endianess was resolved at configure-time or should be resolved at compile-time. For example: #if defined(COMPILE_TIME_ENDIANESS) && defined(__BIG_ENDIAN__) || !defined(COMPILE_TIME_ENDIANESS) && defined(WORDS_BIGENDIAN) /* do big endian thing */ #else /* do little endian thing */ #endif This seems excessively complicated, so I preferred not to do it. Can others comment on the availability of the compiler defined __BIG_ENDIAN__ and __LITTLE_ENDIAN__ variables? Pete
Peter Grayson wrote:> It is not that AC_C_BIGENDIAN does not work. It is that it determines > endianness at configure-time as opposed to compile-time. The process > for building universal binaries on Mac demands that the distinction be > made at compile-time. To enable building universal binaries on Mac in > a single pass, the decision has to be deferred to compile-time.Personally I think universal binaries are a bad idea. For one of my projects, libsndfile, endian issues is not the only think that breaks in univesal binaries. The problem is that I detect cpu features other than just endian-ness at configure time; things that cannot be detected purely from compiler flags. See: http://www.mega-nerd.com/libsndfile/FAQ.html#Q018 However, my biggest objection to universal binaries for libsndfile is that libsndfile has a huge and comprehensive test suite and running the test suite during a universal build will only test the native build, not the cross-compiled build. As far as I am concerned, cross-compiled code that isn't tested is worse than native code that isn't tested and I consider native code that isn't tested to be broken code.> My strong suspicion is that testing __BIG_ENDIAN__ at compile-time > will work for all relevant unix-like platforms. Even icc supports > this.Yep, gcc and icc support it. How many others do? Is suspect its very close to zero. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn
Peter Grayson wrote:> Can others comment on the availability of the compiler defined > __BIG_ENDIAN__ and __LITTLE_ENDIAN__ variables?I should also reply to this. The problem with these macros is that they are not part of any C standard; not 1999 ISO C nor any of the POSIX standards. In fact, these two macros are not even available on Linux/gcc *unless* you include <endian.h>. On MacOSX these macros are defined inside the compiler itself. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Hundreds of thousands of people couldn't care less about Kylix and what it runs on. It's there for the dying breed of die-hard Pascal fanatics who missed their 20 year window to migrate to C and C++." -- Kaz Kylheku in comp.os.linux.development.apps
On 5/3/07, Erik de Castro Lopo <mle+la@mega-nerd.com> wrote:> Peter Grayson wrote: > > Personally I think universal binaries are a bad idea.They have obviously served some purpose, but I tend to agree that the concept does not seem to scale well once outside the Apple microcosm.> For one of my projects, libsndfile, endian issues is not the only > think that breaks in univesal binaries. The problem is that I > detect cpu features other than just endian-ness at configure time; > things that cannot be detected purely from compiler flags. > > See: > http://www.mega-nerd.com/libsndfile/FAQ.html#Q018Can you elaborate on what kind of CPU vagaries come into play besides endianess? Do they affect all code or just highly-optimized code? I have built several open source projects as universal binaries and they basically function. If you know of specific risks to look out for, your experiences would help a lot of people.> However, my biggest objection to universal binaries for libsndfile > is that libsndfile has a huge and comprehensive test suite and > running the test suite during a universal build will only test > the native build, not the cross-compiled build. As far as I am > concerned, cross-compiled code that isn't tested is worse than > native code that isn't tested and I consider native code that > isn't tested to be broken code.Is it just the endianess issue or is it other ill-detected CPU features that cause the libsndfile test suite to fail? Again, your experience would be greatly appreciated.> > My strong suspicion is that testing __BIG_ENDIAN__ at compile-time > > will work for all relevant unix-like platforms. Even icc supports > > this. > > Yep, gcc and icc support it. How many others do? Is suspect > its very close to zero.You are probably right. My argument here was bogus. Although, didn't some features get into the C and POSIX standards by first being non-standard, but useful? In this case, these macros are clearly an insufficient to be regarded as a solution to the problem, but they have proven useful to a number of people, including myself. Thanks for your feedback. Pete
Peter Grayson wrote:> Wow, that is a strange one. I would have suspected the semantic of the > float to int conversion to be well defined by the ISO standard and > that this was a compiler bug.Err, no. The C standard leaves a large number of issues to be undefined which really just means "hardware or implementation dependant". In this particular case I belive this to actually be CPU dependant. It has nothing to do with compiler itself. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Every time an American goes to a gas station, he is sending money to America's enemies." -- http://www.meforum.org/article/653