This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
There is no such thing as "the" configure commandline. I have two different ones. Or three, if you count the libc one...Apparently it's not quite as simple as that, but I've figured it all outIt should get defined if you used "--enable-sjlj-exceptions" on yourUnfortunately, I don't quite get a working setup with this, as the SJLJ exception code isn't correctly built. The problem appears to be that certain routines are compiled only if "__USING_SJLJ_EXCEPTIONS__" is set, which it isn't. And I can't figure out how it's supposed to get defined. "configure" does not define this macro - only (optionally) "CONFIG_SJLJ_EXCEPTIONS". [ ... ]
configure commandline IIUIC.
now. It depends on what configure commandline you are talking about,
The top level configure commandline.
I haven't seen those as the same type of options, though. The big/little endian flags control the low-level code-generation, while the exception type settings look more like options related to the inclusion of libraries or compiler features that are outside the scope of the boostrap build. I mean, that's how other "--enable" or "--disable" setting work (or some of them, at least), and this particular one seems mainly to affect "#ifdefs" that are only really relevant during the final build.Yes, the "bootstrap" (as it is often described in cross-gcc terminology) akaactually, as it turns out that parts of the build rely on macros that are automatically defined by the preprocessor based on the choice of exception type. This means that the compiler you are using for the build, as opposed to the compiler you are building, must be configured via "--enable-sjlj-exceptions". [ ... ]
"minimal" compiler and the final one should *definitely* both be configured
with all the same ABI-related options. You don't want to build one big-endian
and the other little-endian either....
[ ... ]When I said "build compiler", I referred to the compiler used while building the "full gcc" *in general*. I'm not sure I know a different way to describe it. I mean, I was specifically not talking about the "minimal" gcc, as the point I was trying to make, was that I don't know if you have to compile the full gcc with such a separately built compiler.
If you refer to "the build compiler", people will think you are referring to your native compiler,
and that absolutely shouldn't have to have the sameWell, like I said, it does seem natural to change some of the "--enable" or "--disable" settings, too.
configuration options as needed for the target! But yes, you do need the same
configure options for the minimal and full compilers; only things like the
--with-headers/--with-libs/--with-newlib flags should have changed between
them, according to the precise details of your cross-build procedure.
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |