Re: [gtk-osx-users] Universal ppc/i386 build

> Sorry, I don't have time today for a proper answer, but

> will get you started.
> The universal module runs those packages which need it twice and lipos them 
> together. I think
> talks about the process, but you can also look at setup_universal() in .jhbuild 
> and read the man page for lipo.

Thanks for the pointers.

I can see that building a module multiple times, once for each architecture using the (build,host,target) variables and lipo'ing the binaries together should work.  Although, it seems that for 95 % of the source files the universal binary could be generated directly by a single compile run.

But how about header files that are installed in ~/gtk/inst/include?  In glib, for example we have the G_BYTE_ORDER define, which I changed into the following in the configure script:

#if defined(__POWERPC__)
+#elif defined(__i386__)
+    #define G_BYTE_ORDER $g_byte_order

Similar things apply to ffitarget.h in libffi which depends on whether we compile for ppc or x86.

Your second link actually suggest to make use of the preprocessor symbols:

The best fix is to replace configure-time detection of endianness, data type sizes, and so on with compile-time or run-time detection. For example, instead of testing the architecture for endianness to obtain consistent byte order in a file, you should do one of the following:

Use C preprocessor macros like __BIG_ENDIAN__ and __LITTLE_ENDIAN__ to test endianness at compile time.
Use functions like htonl, htons, ntohl, and ntohs to guarantee a big-endian representation on any architecture.
Extract individual bytes by bitwise masking and shifting (for example, lowbyte=word & 0xff; nextbyte = (word >> 8) & 0xff; and so on).

(I just learned that I should have used __BIG_ENDIAN__ and __LITTLE_ENDIAN__ instead of __POWERPC__ and __i386__).

Best regards,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]