This is the mail archive of the gcc-patches@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]

Re: powerpc-eabism, strategy for finding crt0.o


On Thu, Apr 12, 2001 at 12:58:25PM -0700, Geoff Keating wrote:
> > Cc: gcc-patches@gcc.gnu.org, geoffk@cygnus.com, newlib@sources.redhat.com
> > From: Alexandre Oliva <aoliva@redhat.com>
> > Organization: GCC Team, Red Hat
> > Date: 12 Apr 2001 06:35:29 -0300
> > User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
> > 
> > On Apr 12, 2001, Benjamin Kosnik <bkoz@redhat.com> wrote:
> > 
> > >> I suggest the following:
> > >> 
> > >> Move the case ${target} from libgloss/configure.in into a separate
> > >> shell-script fragment, that sets some variable to the (list of)
> > >> directories in which GCC should search for crt files and libraries.
> > >> 
> > >> Then, get the top-level configure.in to source this shell-script
> > >> fragment and add -B$$r/$(TARGET_SUBDIR)/libgloss/$libglosssubdir(s)/
> > >> to FLAGS_FOR_TARGET.
> > 
> > > This would be great. Then everything would "just work" with what is 
> > > currently in CVS for libstdc++-v3.
> >  
> > Yep.  I suppose this new config fragment could also set any additional
> > flags needed for link tests to succeed.  I don't think we need flags
> > specific for the simulator, since I don't think many embedded targets
> > have different triplets for simulator or board set-ups.  Presumably,
> > we only need to be able to link, since, when cross compiling, we don't
> > run configure tests.  So, simulator-specific flags shouldn't be
> > necessary.  Right, Geoff?
> 
> No, the compiler will still need -msim to link correctly for the
> simulator when configured as 'powerpc-eabi'.  It has to be told which
> board it is linking for.

There is still the feature/kludge/whatever that if you configure for
powerpc-eabisim instead of powerpc-eabi, it will default the -msim argument.

I do think, that that we should think about making it easier to configure what
board support is used by default for each of our platforms, to make the OOB
(out of box) experience better for the customers.  This includes provisions for
third party support, etc.

-- 
Michael Meissner, Red Hat, Inc.  (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482


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