This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: committed: merge with libada-branch


Daniel Jacobowitz wrote:

On Tue, Feb 10, 2004 at 12:05:17PM -0800, Zack Weinberg wrote:

Daniel Jacobowitz <drow@mvista.com> writes:


On Tue, Feb 10, 2004 at 11:56:17AM -0800, Zack Weinberg wrote:

The set of multilibs is determined entirely by the target
architecture.  Building a cross compiler to just about any
embedded target (mips-elf for example) will involve multilibs.

You can also build them for an i386 native if you prefer. GCC will happily build multilibs for anything you choose to specify; you could probably multilib on -g if you wanted to.

I was trying for a suggestion that didn't involve mucking with t-fragments, or have I missed something?


Nope. The mucking is pretty straightforward though.

MULTILIB_OPTIONS = g
MULTILIB_DIRNAMES = g

is probably all that is necessary.  Not even sure about the second
line.


If you want to play on the i386 and get multilibs, config/i386/t-rtems-i386 is set up to build a number of
them. We end up with these library variants:


athlon/libc.a
k6/libc.a
m486/soft-float/libc.a
m486/libc.a
mpentium/libc.a
mpentiumpro/libc.a
soft-float/nofp/libc.a
soft-float/libc.a
libc.a

Just cut those and put them in another t- file.

Be warned, turning on multilibs can trigger bugs which were
overlooked before.  I recall that it took a few rounds of bug reports
before we could reliably build i386-rtems with all those multilibs.

--joel


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