Notes
(0003489) Bill Hoffman (manager) 2006-01-02 12:47	How would you propose to add support?

(0003490) Bill Hoffman (manager) 2006-01-02 12:49	So, I suppose if you followed the instructions here: <http://developer.apple.com/technotes/tn2005/tn2137.html> [^] Then cmake already supports it. Just replace configure with cmake: env CFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" \ LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" \ cmake .

(0003491) Bill Hoffman (manager) 2006-01-02 12:52	However, I guess you are looking for a higher level support in CMake for this stuff. Also, the Xcode generator should support this without the flags. There is also the issue, that many try_compiles will not work correctly, but that is up to the application developer to get correct. What CMake support should be done for this? A variable: SET(CMAKE_USE_UNIVERSAL_BINARY TRUE) I am not sure? Any ideas?

(0003500) Eric Wing (reporter) 2006-01-02 14:24	SET(CMAKE_USE_UNIVERSAL_BINARY TRUE) is somewhat deficient and you need additional options, or need to change this option to be more flexible. You would need a way to specify which architectures to support (ppc, ppc64, i386). Most people don't typically use ppc64 and their code is not 64-bit clean/capable, so this would cause people problems if there is no way to specify it on or off. I'm not sure what the CMake convention is for this kind of multi-option field. Maybe you have a boolean field for each architecture? Or maybe you have one field that the user must type in the names of the architectures they want. Since this is essentially cross-compiling, maybe you should think ahead to what CMake would need to support cross-compiling in general since this feature seems to be asked for once in awhile. Universal Binaries would probably be a subset of this. That way any features you implement for Universal Binaries could ultimately be reused to support this. As for TRY_COMPILE, yes, users are going to have to be careful. But maybe some things can be done. Perhaps you could make TRY_COMPILE do multiple passes, one for each architecture. Then a list of results is returned somehow, one item for each architecture. I guess you would need true/false for each, the results log for each, and maybe a key telling the user which entry belongs to which architecture. (This is where a data structure like a map/dictionary might come in handy.)

(0003501) Bill Hoffman (manager) 2006-01-02 14:37	I am begining to think that this should be a FAQ entry, and just let the users pick the flags. Perhaps a module file that gets loaded. At the end of the day this seems to boil down to a bunch of compiler flags. I don't think we want these flags to be the default for the Mac, so then it becomes a per project thing. But I am open to ideas, please post use cases for how cmake would work best with this stuff.

(0003503) Eric Wing (reporter) 2006-01-02 15:16	No, I really think it needs to be more than just a FAQ entry. I think CMake really needs to roll the correct flags for you. TRY_COMPILE is a low priority for me so if you want to push the usage warning about this to the FAQ, I probably won't care. But I think CMake should be doing the dirty work for invoking the Universal Binary flags (and lipo if necessary), particularly because the SDK flags are likely to be dropped with Leopard and possibly the Intel-based Macs as I already have discussed with you somewhere else. There is also a possibility the framework detection code may need to be tweaked to work with the SDK stuff. If so, this should be done at the CMake level. I think I also told you that there is a known bug in Xcode 2.1 where the flags must be in the correct order or things don't work (e.g. -arch ppc -arch i386, not -arch i386 -arch ppc). The CMake (GUI)interface could be something as simple as a field called "Architectures" and you make the user type space separated list of architectures (similar to the Xcode field). SET(CMAKE_ARCHITECTURES "ppc ppc64 i386") (I'm not sure if the default should be "ppc i368" or if you should detect the Native architecture you're running on and substitute that in as the sole default.) Or would semi-colon separated be more consistent with CMake? SET(CMAKE_ARCHITECTURES ppc;ppc64;i386) As for the Mac default, I think Xcode 2.2 activates the Universal SDK by default for the templates but only selects the native architecture by default. For CMake, I'm not sure if a more conservative, "Don't invoke the SDK unless a non-native architecture is listed" approach should be used, or if CMake should emulate this Xcode behavior (or one-up Xcode and select "ppc i386" as the default).

(0003504) Bill Hoffman (manager) 2006-01-02 15:27	How about: SET(CMAKE_OSX_ARCHITECTURES ppc;ppc64;i386) If this is empty, or set to native, then cmake does what it has been doing. If it is set then it adds -arch flags. TRY_COMPILE will be left for the FAQ with a warning to be careful about the use.

(0003505) Eric Wing (reporter) 2006-01-02 15:33	I think this will work for me. How about you, Sean?

(0003506) Eric Wing (reporter) 2006-01-02 15:41	Oh, I probably should qualify that in addition to the -arch stuff, I need it to also set the SDK flags for at least 10.4/PPC. 10.5 who knows. 10.4/Intel, not sure...consistent with 10.4/PPC probably won't hurt though.

(0003511) 2006-01-04 09:58	I'm very happy to see this discussion, but I'm afraid I don't have much to offer. I filed this bug as a first step do getting universal versions of vtk. I've never written a cmake script, so I'm not really qualified to comment on how it would be best supported. I know only that I need it. :)

(0003512) Sean McBride (reporter) 2006-01-04 10:01	I'm happy to see this discussion, but I'm afraid I don't have much to offer. I've never made a cmake script, I only use cmake to build vtk. I filed this bug as a first step to be able to have a universal vtk.

(0003557) 2006-01-13 12:45	In case you missed the announcement, Apple has already started shipping the first Intel based Macs. That means the need for this ability is now a for-real issue. To throw yet another monkey wrench into the thing, I have found another issue. Everything that has been said here is still true, but I've found more specific issues where projects with less-than-straight-forward build requirements will have problems. I've been working on SDL's current build system to produce Universal Binaries. As I've said, I've been considering using CMake as a future replacement just so we don't have the synchronization issue between build systems any more (though we still need the Framework building support feature too :) But in crafting just the current build system issue, we've had to resort to architecture specific flags. This goes against the grain of what we had talked about before in emails when discussing single-shot (-arch ppc -arch i386) approach vs. a multiple pass approach (calling each -arch separately) via the Makefiles. There are several different issues with SDL. The primary issue is that the code base has CPU specific optimizations for both Altivec and SSE. In Xcode, Apple has apparently provided a set of flags that can be specified as architecture specific: http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeUserGuide/Contents/Resources/en.lproj/05_07_bs_building_product/chapter_33_section_6.html [^] So to pull this off in Xcode using those, I set OTHER_CFLAGS_ppc=USE_ALTIVEC OTHER_CFLAGS_i386=USE_SSE and OTHER_CFLAGS=$(OTHER_CFLAGS_$(CURRENT_ARCH)) I know it's not common to have CPU specific optimizations in the source base, but it probably happens enough in projects that this needs to be thought about. A second complication for SDL is that we have a backwards compatibility requirement with 10.2. We discovered from testing that gcc 4.0 will not work for this because of symbols or dependencies it has. But gcc 4.0 is required for Intel. So we must set the GCC_VERSION flags accordingly. GCC_VERSION_ppc=3.3 GCC_VERSION_i386=4.0 We also had to do a few other things to make this work more smoothly: MACOSX_DEPLOYMENT_TARGET_ppc=10.2 MACOSX_DEPLOYMENT_TARGET_i386=10.4 This one we're still experimenting with but the flexibility has proven to be very useful: SDKROOT_ppc=/Developer/SDKs/MacOSX10.2.8.sdk SDKROOT_i386=/Developer/SDKs/MacOSX10.4u.sdk Anyway, as far as CMake support goes, for the Xcode generator, if there was a way to access the 8 per-architecture flags (from the link above), then CMake probably won't need to do anything special. Perhaps there might already be a way to access these through standard CMake APIs? As for the Makefile generator, I'm guessing things get more challenging. I think a multiple pass system may need to be adopted. But to start with, I would probably recommend focusing on the Xcode generator since it will probably be easier. Then look at getting at least the single pass solution working for the Makefile generator. Then finally figure out how to do the multi-pass.

(0003558) Eric Wing (reporter) 2006-01-13 12:46	In case you missed the announcement, Apple has already started shipping the first Intel based Macs. That means the need for this ability is now a for-real issue. To throw yet another monkey wrench into the thing, I have found another issue. Everything that has been said here is still true, but I've found more specific issues where projects with less-than-straight-forward build requirements will have problems. I've been working on SDL's current build system to produce Universal Binaries. As I've said, I've been considering using CMake as a future replacement just so we don't have the synchronization issue between build systems any more (though we still need the Framework building support feature too :) But in crafting just the current build system issue, we've had to resort to architecture specific flags. This goes against the grain of what we had talked about before in emails when discussing single-shot (-arch ppc -arch i386) approach vs. a multiple pass approach (calling each -arch separately) via the Makefiles. There are several different issues with SDL. The primary issue is that the code base has CPU specific optimizations for both Altivec and SSE. In Xcode, Apple has apparently provided a set of flags that can be specified as architecture specific: http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeUserGuide/Contents/Resources/en.lproj/05_07_bs_building_product/chapter_33_section_6.html [^] So to pull this off in Xcode using those, I set OTHER_CFLAGS_ppc=USE_ALTIVEC OTHER_CFLAGS_i386=USE_SSE and OTHER_CFLAGS=$(OTHER_CFLAGS_$(CURRENT_ARCH)) I know it's not common to have CPU specific optimizations in the source base, but it probably happens enough in projects that this needs to be thought about. A second complication for SDL is that we have a backwards compatibility requirement with 10.2. We discovered from testing that gcc 4.0 will not work for this because of symbols or dependencies it has. But gcc 4.0 is required for Intel. So we must set the GCC_VERSION flags accordingly. GCC_VERSION_ppc=3.3 GCC_VERSION_i386=4.0 We also had to do a few other things to make this work more smoothly: MACOSX_DEPLOYMENT_TARGET_ppc=10.2 MACOSX_DEPLOYMENT_TARGET_i386=10.4 This one we're still experimenting with but the flexibility has proven to be very useful: SDKROOT_ppc=/Developer/SDKs/MacOSX10.2.8.sdk SDKROOT_i386=/Developer/SDKs/MacOSX10.4u.sdk Anyway, as far as CMake support goes, for the Xcode generator, if there was a way to access the 8 per-architecture flags (from the link above), then CMake probably won't need to do anything special. Perhaps there might already be a way to access these through standard CMake APIs? As for the Makefile generator, I'm guessing things get more challenging. I think a multiple pass system may need to be adopted. But to start with, I would probably recommend focusing on the Xcode generator since it will probably be easier. Then look at getting at least the single pass solution working for the Makefile generator. Then finally figure out how to do the multi-pass.

(0003559) Bill Hoffman (manager) 2006-01-13 13:20	I am having trouble following all of this. Are you saying that this will not work: <http://developer.apple.com/technotes/tn2005/tn2137.html> [^] Then cmake already supports it. Just replace configure with cmake: env CFLAGS="-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" cmake . It seems crazy that you have to use Xcode to build this stuff. Apple must have some way of supporting the makefile configure crowd as they are a large group. In fact much of the stuff on apple is built with configure and not Xcode. There must be some simple instructions of how to do this by setting flags on the compiler.

(0003560) Sean McBride (reporter) 2006-01-13 13:49	I have used the tn2137 technique to build some cross platform libraries (configure/make, not CMake). It works. Note though that tn2137 has some errors, see this thread: <http://lists.apple.com/archives/unix-porting/2005/Oct/msg00003.html> [^] So you're saying if I change the CMAKE_C_FLAGS:STRING part of my .cmake file, I can add in the flags the technote mentions? And it should be that easy? Eric's last point is still important though, building for intel means one must use gcc 4, using gcc 4 means one can't support older than 10.3.9. So consider vtk. Do we want vtk to still work on pre-10.3.9? If so, I need a way to tell cmake to use gcc 3.3 for ppc and 4.0 fro intel. How can that be done?

(0003562) Bill Hoffman (manager) 2006-01-13 14:29	Yes, I am saying that if you change CMAKE_C_FLAGS and CMAKE_CXX_FLAGS and possibly some linker flags it should all work. As for using gcc3.3, you just have to set CXX and CC in your environment prior to running cmake or ccmake to the compiler you want to use, and cmake will use it.

(0003563) Sean McBride (reporter) 2006-01-13 14:42	OK, I'll try building vtk that way. But for the compiler selection... I'm not sure you understand... We need to use BOTH compilers, gcc3 for ppc and gcc 4 for intel. I think we need a way to 'specialise' like how there is a debug version of the following: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG We also need a CMAKE_CXX_FLAGS_PCC and CMAKE_CXX_FLAGS_INTEL type of thing. This is what you're talking about too, right Eric?

(0003564) Eric Wing (reporter) 2006-01-13 14:44	> CFLAGS=\\\\\\\"-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc\\\\\\\" > LDFLAGS=\\\\\\\"-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk\\\\\\\" As I said, this only works in the cases where everything is unified. In SDL\\\\\\\'s case where flags must be passed in a per-arch case, this will not work. Just think about it: CFLAGS=\\\\\\\"-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -DSDL_USE_ALTIVEC -DSDL_USE_SSE\\\\\\\" How is gcc going to know that SDL_USE_ALTIVEC should only be applied to the PPC variant and SDL_USE_SSE to the i386? Both flags are obviously going to be passed to both architectures which will probably result in bad things. What I need is separate CFLAGS: CFLAGS_ppc=\\\\\\\"-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -DSDL_USE_ALTIVEC\\\\\\\" CFLAGS_i386=\\\\\\\"-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -DSDL_USE_SSE\\\\\\\" The above also fails to address specifying different gcc versions for each architecture. Xcode isn\\\\\\\'t required, but Apple has been strongly encouraging its use for obvious reasons. As far as what the autoconf people are doing, I really don\\\\\\\'t know. I suspect some of them don\\\\\\\'t care yet, some of them don\\\\\\\'t have these problems as they can pass unified options, and I suspect some of them are still struggling with this. (I know we\\\\\\\'re not the only ones dealing with the gcc 4.0 compatibility issue.) I have been wondering if the autoconf community is going to try to address these problems directly in the tool set or if each project is going to reinvent it.

(0003565) Eric Wing (reporter) 2006-01-13 14:53	> We also need a CMAKE_CXX_FLAGS_PCC and CMAKE_CXX_FLAGS_INTEL type of thing. This is what you're talking about too, right Eric? Right. The link I pointed to contains the Xcode magic 8: SDKROOT OTHER_CFLAGS OTHER_LDFLAGS OTHER_LIBTOOLFLAGS GCC_VERSION MACOSX_DEPLOYMENT_TARGET LD LDPLUSPLUS Each one of these flags contains an architecture specific variant (_ppc, _ppc64, _i386) which will handle the cases I describe. However, only Xcode responds to these and Xcode does the translation to gcc. So for the CMake Makefile generator, CMake would need to duplicate Xcode's efforts here to support the same. For the Xcode generator, the ideal would be just to pass the buck.

(0003573) Bill Hoffman (manager) 2006-01-16 22:30	I am thinking most open source projects will just not ship universal binaries. They will ship source, and you will build it on your Mac. Or they will have one for intel and one for powerpc. Or they will build one on each, then combine them. So projects like VTK are fine, you get the source and build it for your machine. For CMake I plan to just have an intel and a powerpc version of cmake on the download page. As for this stuff: CFLAGS=\\\"-O -g -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -DSDL_USE_ALTIVEC -DSDL_USE_SSE\\\" You might be able to make the above work. You could use these: __i386__ and __ppc__ which are preprocessor defines. So, #if defined(SDL_USE_ALTIVEC) && defined(__ppc__) .... #endif #if defined(SDL_USE_SSE) && defined(__i386__) ... #endif I really don't like solutions that only work for one generator, as someone will report a bug about something not working as soon as we do it. I also think we are a long we off from the makefile generator building two of everything for the Mac. So, I would like to get the single build to work.

(0003576) Bill Hoffman (manager) 2006-01-17 10:34	So, here is what I propose. I will create a general way to set Xcode variables : SDKROOT OTHER_CFLAGS OTHER_LDFLAGS OTHER_LIBTOOLFLAGS GCC_VERSION MACOSX_DEPLOYMENT_TARGET LD LDPLUSPLUS There is another bug report asking for this type of thing. I will also create a way to enable the default dual build in Xcode. Perhaps with a single flag: CMAKE_XCODE_PPC_I386_BUILD_CONFIGURATIONS Debug\|Release\|MinSizeRel For each configuration that you set, it will enable ppc and i386 builds. This will set the few extra options that make a project build both ppc and i386 for the specified configuration types. For setting the xcode variables, I am thinking a combination of a cmake variable with a list of pairs: CMAKE_XCODE_VARIABLES var1;value1;var2;value2 And a target property XCODE_VARIABLES that can be set to the same type of list. It could also have configuration types as well. CMAKE_XCODE_VARIABLES_DEBUG CMAKE_XCODE_VARIABLES_RELEASE For the makefiles, you will just have to follow the instructions for configure projects, i.e set the cflags , ldflags, and cxxflags correctly. I think I can do the above in a reaonable amount of time. Does it sound like it would work?

(0003593) Sean McBride (reporter) 2006-01-23 12:57	Well, a universal build of vtk is now in progress... we'll see how it goes... but one thing worries me right away. When I start the build process, it prints a bunch of things like this: -- Check size of short -- Check size of short - done -- Check size of uchar -- Check size of uchar - failed -- Check if the system is big endian -- Check if the system is big endian - big endian -- Configuring done -- Generating done What does this imply? "Check if the system is big endian - big endian". Who cares what endianness the build computer is? Is there a hardcoded assumption in there somewhere that my build machine is the same architecture as what I'm building for? This seems to be exactly whan apple warns of in TN2137: "Many open source projects use a build-time configuration script to determine the environment in which the program will compile and run, including machine information (such as CPU type, word order and pointer size), and which header files and libraries are available on the system...{snip}...the problem arises because the configure environment was not envisioned with a universal binary-like situation in mind."

(0003594) Bill Hoffman (manager) 2006-01-23 13:09	This is really a VTK issue. There is not much CMake can do to help here. The VTK code has to be changed to do the right Mac thing for big/little endian.

(0003595) Eric Wing (reporter) 2006-01-23 15:38	> I am thinking most open source projects will just not ship universal > binaries. They will ship source, and you will build it on your Mac. Or > they will have one for intel and one for powerpc. Careful here. There is a distinction between "most" open source projects and open source projects that support OS X. "Most" open source projects only compile on one platform (I used to assume Linux, but I've run across huge numbers of Windows only projects in the past year) because the authors never thought about porting it, in which case, they are probably not using CMake. Of the projects that do support OS X, binaries are usually shipped because like Windows, users are not generally expected to compile things themselves so binaries are prebuilt. And of the OS X open source projects that do ship binaries, most I know of are already in the process of going Universal. This is no accident. Apple has put their marketing clout behind the term and concept of "Universal Binaries" (renamed from Fat Binaries from the NeXT days) so Mac users are already fully expecting their applications to be "Universal". There is even a marketing program and logo to go with it now. And there are actual non-Apple watchlists keeping tabs on which apps have gone Universal. > Or they will build one on each, then combine them. As for building each one separately on each architecture, that's probably not going to happen. Most open source projects are happy to just find OS X developers to help contribute as they are usually in small numbers. It's already a pain for most open source projects to test 10.2, 10.3, and 10.4. Being able to find developers with access to two machines (both architectures) is going to be painful. > For CMake I plan to just > have an intel and a powerpc version of cmake on the download page. As far as CMake is concerned, because it is a developer centric tool, you can probably get away with having two separate binaries. But I would recommend/encourage you to consider shipping a Universal Binary for marketing reasons (as marketing seems to be on CMake's radar at the moment). Not having a Universal Binary will probably reflect badly upon CMake by Mac users. It may not be fair, but it will be judged by that. Remember that the download link will be the last thing the user experiences before committing to downloading to try out. I can imagine Mac users who are investigating CMake might conclude the software is no good because 'they can't even ship a Universal Binary'. And they'll move on without even downloading the software to actually try it. > I really don't like solutions that only work for one generator, as > someone will report a bug about something not working as soon as > we do it. I also think we are a long we off from the makefile > generator building two of everything for the Mac. So, I would like to > get the single build to work. As nice as it would be to have all the generators handle this, the need to produce Universal Binaries is now. So I really think a pragmatic approach needs to be taken and get the Xcode support in now for the "monkey wrench cases". Then at some point, figure out what to do about the Makefile generator and multiple passes. (I still recommend approaching this from a more general, 'what needs to be done for general cross-compiling support' so everybody might benefit. I hear people use the current SDL autoconf system to cross-compile for platforms like Xbox and Playstation.) And don't feel that the work you put into this will be obsolete anytime soon. Universal binaries will probably be with us for at least the next 7 years. I wouldn't be surprised to see a new variant for x86-64 in the near-mid future. I also wouldn't rule out the possibility of a future architecture switch. Remember, Fat binaries existed for NeXT along time ago and supported something like 5 architectures, so they have been around. The feature laid dormant from the time when NeXT swallowed Apple, but they are back after almost a decade. > So, here is what I propose. I will create a general way to set Xcode > variables : ... > I think I can do the above in a reaonable amount of time. > Does it sound like it would work? I think most of this will work and sounds reasonable. So to set something like gcc 3.3 with -DUSE_ALTIVEC for PPC and gcc 4.0 with -DUSE_SSE for Intel, I would do something like this? SET(CMAKE_XCODE_VARIABLES "GCC_VERSION_ppc;3.3;GCC_VERSION_i386;4.0;OTHER_CFLAGS_ppc;-DUSE_ALTIVEC;OTHER_CFLAGS_i386;-DUSE_SSE") The build configuration variant stuff looks interesting. It hasn't been on my radar, but it could be useful. > There is another bug report asking for this type of thing. I will also > create a way to enable the default dual build in Xcode. Perhaps with > a single flag: > CMAKE_XCODE_PPC_I386_BUILD_CONFIGURATIONS Debug\|Release\|MinSizeRel I don't fully understand how to use this one. But one thing that does seem to be missing is support for ppc64. Also in general, the one thing I would suggest is that an easy way to enable Universal Binaries is needed for both Xcode and Makefiles. Not all cases will have the "monkey wrench" scenarios I mentioned, in which case it would be nice to just enable Universal Binaries and have all the default flags invoked for us. I think the idea we discussed earlier for (SET(CMAKE_OSX_ARCHITECTURES ppc;ppc64;i386)) was a good one. Seeing this setting in the basic ccmake GUI would be a good idea too. For Makefiles, I think you can pull this off since you only need a one pass solution in the simple case.

(0003596) Sean McBride (reporter) 2006-01-23 16:17	>> For CMake I plan to just >> have an intel and a powerpc version of cmake on the download page. > >As far as CMake is concerned, because it is a developer centric tool, >you can probably get away with having two separate binaries. But I would >recommend/encourage you to consider shipping a Universal Binary for >marketing reasons (as marketing seems to be on CMake's radar at the >moment). Not having a Universal Binary will probably reflect badly upon >CMake by Mac users. It may not be fair, but it will be judged by that. >Remember that the download link will be the last thing the user >experiences before committing to downloading to try out. I can imagine >Mac users who are investigating CMake might conclude the software is no >good because 'they can't even ship a Universal Binary'. And they'll move >on without even downloading the software to actually try it. I wholeheartedly agree here! People that see 2 seperate download links for ppc and intel will say "geez, if the cmake ppl themselves don't have a universal binary, will I be able to make one?"

(0003597) Bill Hoffman (manager) 2006-01-23 16:59	At this point, I feel like dropping support for the Mac. :) It is 5% of the market, and 90% of the work. I think fat binaries are an abomination. However, I am willing to move forward, but I do need help from Mac developers. It is a TON of work to do the dual build makefiles, so unless someone does it, I don't think we will have the time/money to do it any time soon. Adding a few flags to Xcode is most likely easy. Also, adding some default flags that can be used is not that hard. BTW, can you put the flags you used to build VTK in this bug? I could try building CMake with the same flags. I don't think cmake will have the same endian troubles as VTK.

(0003598) Sean McBride (reporter) 2006-01-23 17:03	OK, so I'll talk to the vtk people about vtk's problems, but cmake has the same problem I think! Building it also says: -- Check size of int -- Check size of int - done -- Check if the system is big endian -- Check if the system is big endian - big endian So although I successfully built cmake (and vtk btw) as universal by simply adding "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" I wonder if it will _run_ correctly on the other architecture, since it detected my build machine as big endian? Also, everything in /bin (like ccmake, cmake, etc.) is universal but the test apps in /Tests (like ObjC++/objc++) are ppc only. Why did they not also get built as universal?

(0003599) Sean McBride (reporter) 2006-01-23 17:48	Here's my first cmake universal build: <http://www.cmake.org/Testing/Sites/RogueResearch2/MacOSX10.4.4-gcc4.0.1-Universal/20060123-2144-Experimental/Notes.html> [^]

(0004767) Alex Neundorf (developer) 2006-08-27 10:56	AFAIK there is support for universal binaries in cmake 2.4.3 ? So, can it be closed ?

(0004782) Sean McBride (reporter) 2006-08-28 10:47	I've closed it.

Issue History
Date Modified	Username	Field	Change
2016-06-06 16:35	Brad King	Resolution	open => fixed
2016-06-06 16:35	Brad King	Description Updated

Relationships