All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2 V2] Move libgcc inclusion from common Makefile to platform configs files
Date: Sat, 20 Jun 2009 11:59:59 -0400	[thread overview]
Message-ID: <200906201159.59936.vapier@gentoo.org> (raw)
In-Reply-To: <20090620135751.GK3849@game.jcrosoft.org>

On Saturday 20 June 2009 09:57:51 Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:33 Sat 20 Jun     , Mike Frysinger wrote:
> > On Saturday 20 June 2009 09:01:36 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 08:57 Sat 20 Jun     , Mike Frysinger wrote:
> > > > On Saturday 20 June 2009 07:30:41 Jean-Christophe wrote:
> > > > > On 07:08 Sat 20 Jun     , Mike Frysinger wrote:
> > > > > > On Saturday 20 June 2009 06:40:07 Jean-Christophe wrote:
> > > > > > > On 06:18 Sat 20 Jun     , Mike Frysinger wrote:
> > > > > > > > On Saturday 20 June 2009 05:33:26 Jean-Christophe wrote:
> > > > > > > > > This patch moves the libgcc Makefile inclusion from the
> > > > > > > > > toplevel Makefile to the arch_config.mk files. This is in
> > > > > > > > > preparation for the ARM architecture to move away from
> > > > > > > > > including libgcc function and only using self-contained
> > > > > > > > > U-Boot functions as done in Linux.
> > > > > > > >
> > > > > > > > why not change the top level Makefile to read:
> > > > > > > > PLATFORM_LIBGCC ?= ...
> > > > > > > >
> > > > > > > > then any board/arch that doesnt want it can simply do:
> > > > > > > > PLATFORM_LIBGCC = # dont want it
> > > > > > >
> > > > > > > because you need to provide the equivalent functions for
> > > > > > > standalone application and api and U-Boot ofcourse
> > > > > >
> > > > > > so move it to config.mk.  this doesnt change the important point:
> > > > > > leave PLATFORM_LIBGCC default in the toplevel common files.  what
> > > > > > i proposed doesnt limit what you want to do with arm in any way.
> > > > >
> > > > > I think it's better to let it at arch level and force any new arch
> > > > > adding to manage it instead provide a default one
> > > >
> > > > considering most arches want this code, i dont think so.  you're
> > > > proposing we duplicate the same common code in all arches to support
> > > > one deviating arch -- arm.  the defaults should reflect the common
> > > > state while the deviating ones change the behavior as they like.
> > >
> > > This is where I disagree other arch as mips and other will also need to
> > > move away from the needs to include libgcc to be really toolchain
> > > independant
> > >
> > > I do think it's really important for U-Boot be able to have full
> > > control to have a functions embedded into.
> > >
> > > So stop to have libgcc include by default will really reflect it
> >
> > so you have two arches (mips/arm) that you dont want to use libgcc.  that
> > is still vastly the minority.  if we ever do get most ports not using
> > libgcc, then pushing it to the arch configs makes sense.  but we havent
> > and we arent even close.
>
> which minoroty?

the majority use libgcc

> I just give you example but you will see arm, mips, sh, powerpc etc...
> toolchains problem just because we use the libgcc

4 is still the minority, but this is Woflgang's call

> I've patch in qualification for mips and sh so it will not be so long
> maybe 2 or 3 weeks

considering my proposed change is much simpler, and would allow for trivial 
migration as you converted things, it still makes more sense.

> > how you want to manage libgcc dependency is your prerogative ... it
> > doesnt mean you should be forcing other people to follow suit.
>
> you can do your own choice but I steel think it's a good improvement

it depends on the arch.  for ones doing stupid things (like arm), thats one 
thing.  but for others, it's simply a waste of time and unnecessary overhead.  
i'm not about to *copy* the exact sources from gcc just to avoid -lgcc.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090620/52ae8c6e/attachment.pgp 

  reply	other threads:[~2009-06-20 15:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-20  9:33 [U-Boot] [PATCH 1/2 V2] Move libgcc inclusion from common Makefile to platform configs files Jean-Christophe PLAGNIOL-VILLARD
2009-06-20  9:33 ` [U-Boot] [PATCH 2/2 V2] ARM: Don't include libgcc anymore Jean-Christophe PLAGNIOL-VILLARD
2009-06-21 12:25   ` Dirk Behme
2009-06-20 10:18 ` [U-Boot] [PATCH 1/2 V2] Move libgcc inclusion from common Makefile to platform configs files Mike Frysinger
2009-06-20 10:40   ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-20 11:08     ` Mike Frysinger
2009-06-20 11:30       ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-20 12:57         ` Mike Frysinger
2009-06-20 13:01           ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-20 13:33             ` Mike Frysinger
2009-06-20 13:57               ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-20 15:59                 ` Mike Frysinger [this message]
2009-06-20 17:15                   ` Jean-Christophe PLAGNIOL-VILLARD
2009-07-10 22:27                     ` Wolfgang Denk
2009-06-22 18:55                 ` Scott Wood
2009-07-04 21:52 ` Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906201159.59936.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.