Well that is why I am using LLVM bit code as the object file format (I have -emit-llvm lying in my Makefile's CFLAGS) as it is largely ABI and platform insensitive. And I also have -ffreestanding to make sure that the resulting bit code is suitable for bare metal execution.
发自我的 iPhone 在 2013-6-9，6:04，Ivan Vučica <ivuc...@gmail.com> 写道： > Hi Maxthon, > > I believe you'll really want to compile everything on the same platform, or > cross-compile for the target platform. I don't think you'll be able to easily > mix code targeting the GNUstep runtime with code targeting the NeXT runtime. > > The only reason that I can think of why you might have to try getting away > with mixing code compiled for different runtimes is binary compatibility -- > which is what Luboš is trying to achieve :-) > > Any other use case (including putting portions of the Objective-C runtime and > GNUstep into a kernel) should really involve compiling on a single machine, > with a single compiler; mixing compiler, target runtimes, et cetera in the > same binary means only asking for trouble down the road, even without > involving things like "figuring out if a pointer points to a small or regular > object"... > > On Sat, Jun 8, 2013 at 11:51 PM, Chan Maxthon <xcvi...@me.com> wrote: >> I am sort of looking into the concept of running Objective-C in a kernel of >> an operating system, which would require implementing a (partial) libobjc2 >> and Foundation that can run on bare metal. Since all my develop machines >> have clang I can exchange compiled object files in LLVM bitcode and only the >> linking would ask for a Linux box. This is why I am asking this question. >> >> 发自我的 iPhone >> >> 在 2013-6-9，5:15，Ivan Vučica <ivuc...@gmail.com> 写道： >> >>> On Sat, Jun 8, 2013 at 9:55 PM, Chan Maxthon <xcvi...@me.com> wrote: >>>> I am expecting a solution that works on both OS X and GNUstep. >>> >>> Why? >>> >>> This is an implementation detail which can differ on OS X and GNUstep. As >>> far as I understand it, it's only needed inside CoreBase/Core Foundation. >>> Why would you need to even determine if something is a small pointer in >>> another library? >>> >>> Luboš can correct me if I'm wrong, but you don't need to know whether the >>> pointer is a "small object" outside very small amount of runtime code and >>> toll-free bridging-related code, which will be implemented in core GNUstep >>> libraries; and for any binary compatibility you will not and should not >>> need to know this implementation detail about the kind of object that is >>> stored in a pointer. >>> >>> Right? :-) >>> -- >>> Ivan Vučica - i...@vucica.net >> >> _______________________________________________ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > -- > Ivan Vučica - i...@vucica.net >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
