From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Thu, 2 Jul 2015 07:49:21 +0200 Subject: [U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address) In-Reply-To: <55947A25.5020702@gmail.com> References: <1423571865-8579-1-git-send-email-yamada.m@jp.panasonic.com> <20150416112144.3a6b4813@lilith> <20150701234229.705fe4ce@lilith> <20150701215017.6E0DB38100A@gemini.denx.de> <20150702000427.562195b4@lilith> <55947A25.5020702@gmail.com> Message-ID: <20150702074921.7f9bc12c@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Daniel, (not sure how in my previous reply I managed to drop Masahiro off the discussion; fixing that, and apologies) On Thu, 02 Jul 2015 01:39:17 +0200, Daniel Schwierzeck wrote: > > > Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD: > > Hello Wolfgang, > > > > On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk wrote: > > > >> Actually I think it is inherently wrong to enable > >> CONFIG_USE_PRIVATE_LIBGCC by default. > >> > >> This option is intended as a workaround for broken toolchains, until > >> these get fixed. By enabling this by default, we miss do not notice > >> the problems our tool chain has, and therefore these never get fixed, > >> i. e. brokenness grows. This cannot be good. > >> > >> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but > >> never ever a default setting. > > > > Well then, should we not revisit commits c3dd823 and 7bfd5ee, which > > enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either > > we allow it by default for all architectures, or we forbid it by > > default for all architectures, but I don't like the idea of a > > heterogeneous per-arch default setting. > > > > CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports > a private libgcc, then it should always use it. I think for U-Boot it is > better and safer to have all code under control instead of pulling in > external code from toolchains which are often somehow broken. > > Speaking for MIPS we have boards with all combinations of Big > Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc > binary for each FPU variant, but almost no toolchain supports this. Thus > you need different toolchains for different boards. This is a PITA for > users or developers who want to use buildman. Always using > CONFIG_USE_PRIVATE_LIBGCC=yes was the only painless way so far. That is > why we chose to enable CONFIG_USE_PRIVATE_LIBGCC by default. > > BTW: Linux kernel or Barebox always use a private libgcc. Seems like there is room for debate on the topic, then, which I'll start in another topic. >From a short-term perspective, I will defer the present patch because applying it makes U-Boot support fifteen less targets than not applying it, which I think we can agree goes in the cons list of both approaches. > -- > - Daniel Amicalement, -- Albert.