[cfe-dev] Fwd: [PATCH]: add support for FreeBSD
daniel at zuster.org
Fri Oct 10 09:35:32 PDT 2008
uname is implemented in terms of uname(), which is what the
llvm::host::osName() and llvm::host:::osVersion() functions I
added are querying. However, the plan is to replace those with
one function which just constructs the target triple of the host.
Will such a function suffice for doing the right thing on FreeBSD?
On Fri, Oct 10, 2008 at 8:17 AM, Chris Lattner <clattner at apple.com> wrote:
> bringing back to the mailing list
> Begin forwarded message:
> > From: Chris Lattner <clattner at apple.com>
> > Date: October 10, 2008 8:16:59 AM PDT
> > To: Roman Divacky <rdivacky at freebsd.org>
> > Subject: Re: [cfe-dev] [PATCH]: add support for FreeBSD
> >>> I think that wrapping the configuration logic with #ifdef
> >>> __freebsd__
> >>> (or whatever is appropriate) would make sense. Follow the lead of
> >>> the
> >>> similar darwin code.
> >> thats not the problem :) the problem is that the given header file
> >> does not have to be present on the machine we are building at.
> >> it's an internal freebsd sources header file.
> > Ah ok, that won't work then.
> >>>> I might ignite a discussion on the fbsd mailing list if we can
> >>>> change
> >>>> the sources to export these two numbers to be exported in some
> >>>> header file.
> >>> On darwin, we autodetect using the "approved system interfaces".
> >>> The
> >>> idea is that we want to be able to build a binary on darwin9 and
> >>> have
> >>> it run find on darwin10. The idea is that we want the compiler to
> >>> default to generating code for the current OS, but that requires
> >>> detecting it (since the build may have been done on a different
> >>> one).
> >>> Make sense?
> >> well.. I could parse output of "touch dummy_file.c ; gcc -E -dM
> >> dummy_file.c"
> >> to get the two defines. there's no other way to get this on
> >> runtime, is
> >> this an acceptable solution?
> > I'm confused about why that would be useful. Worst case you could
> > parse the output of 'system("uname -a")' or something, no?
> > Presumably uname is implemented in terms of some library/system
> > call, and that could just be used instead?
> > -Chris
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev