This is the mail archive of the crossgcc@sources.redhat.com 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]

Re: Cross compile error question: i686 to powerpc--linux-gnu


Marcus:


> Heh, I can tell you that... they're built as part of libgcc, which
> gets built whether you're building a bootstrap compiler or not.
> That much isn't rocket science.

See, I *knew* I'd draw out someone who actually knew!  Knowledge wants
to be free, thanks for saving me the research.  :^)

> The only reason gcc needs to rely on system headers and libraries is
> for threading and shared library support (e.g. building a threaded
> and/or shared version of libgcc and startup files) and for building
> higher-level components like libiberty and g++. For System V ABI
> targets, Linux, etc. it does *link* with startup files that don't
> exist until glibc is built and installed.

Oooh, let's constrain ourselves to the 2.95.x series, ok?  I'm still
reeling with the differences in 3.x...  :^)

I think I'm correct in saying that the "all-gcc" target stops before
building libiberty, but after building libgcc, no?

> Startup files are partially gcc's responsibility and partially ld's
> responsibility - the linker script specifies the main startup file,
> but gcc's specs often define "variants" of those startup files
> (e.g. for C++ constructor/destructor code, profiling, etc.).

Right.  The -m options in particular.

> Actually, if you do an unsigned 32-bit integer division on the SH
> you do *need* __udivsi3_i4, whether you're building library code or
> application code - it's a compiler intrinsic and you can't escape it
> :P.  Whether or not libgcc is linked statically or shared depends on
> if you're using 3.0+, and whether you've bothered to build the full
> compiler.

Right, but you don't need the intrinsics until you actually try to do
a fully-resolved link, i.e. an executable.

> It's a Good Thing as long as you know how to "opt-out" of certain
> compilerisms by using gcc's extensive options.  I'd suggest anyone
> seriously working with gcc read it's info pages, particulary the node
> "Invoking GCC".  Especially read up on target-specific options.

Gcc is quite "opt-outable".  That's (partly) why I likes it.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]