[Mono-dev] monoburg and eglib

Andreas Färber andreas.faerber at web.de
Tue May 8 13:58:06 EDT 2007


Hi Paolo,

>> this way of building breaks on Mac OS X when using
>> eglib because gcc is directly being passed eglib's .la file in place
>> of the usual -lglib-2.0 flag.
>>
>> How should this be fixed?
>
> When not cross-compiling you might want to set BUILD_GLIB_LIBS and
> BUILD_GLIB_CFLAGS to GLIB_LIBS and GLIB_CFLAGS in configure.in.

As far as I can tell this is already being done.

The problem is rather with [BUILD_]GLIB_LIBS being applied to *gcc*  
in one step instead of doing .c ->(gcc) .o; .o + .la ->(*libtool*)  
monoburg. This is independent of cross-compiling or not.  
Unfortunately the auto* manuals have not shed any light on what  
variables to use in place of CC_FOR_BUILD to continue to allow cross- 
compiling while fixing this for OS X (the simplest fix for me was to  
use the usual automake way of building but that breaks cross-compiling).

Also, in theory I *am* actually cross-compiling from ppc to ppc64,  
only does Apple's (or Solaris') gcc not use the "classic" way of  
cross-compiling but stuffs this functionality via custom switches  
into one gcc so that configure does not know about it. (On both  
platforms uname -a does not indicate what exact platform I am on and  
the target platform is set using -arch <architecture>, not by  
selecting a different gcc executable.)

On OS X v10.4 the only 64-bit library is libSystem (=libc), and  
compiling glib for ppc64 failed, thus I have patched eglib to have a  
glib at all. So given that there is no distinction between host and  
target I do not see a way how I could easily compile part of Mono 32- 
bit w/[e]glib and another 64-bit w/eglib, which would be the best  
solution for the eglib/test trouble (which assumes there is a usable  
glib and tries to compile against it as part of "make").

> When cross-compiling a different eglib would need to be compiled.

What do you mean by this?

> Another solution is to remove glib use from monoburg, the stuff used
> is quite small (and a fixed-size hash table is good enough for this
> tool, the rest is just a list imple, basically).

Well, the whole point of [e]glib is to avoid rewriting code  
everyplace, no? It would therefore seem more efficient to fix this  
simple build issue for now and only at some point in the future  
enhance Mono's cross-compilation support in general.

Btw I've already had a shot at fixing some VPATH issues with eglib  
and Mono and hope to provide a patch end of the week.

Andreas



More information about the Mono-devel-list mailing list