From mboxrd@z Thu Jan 1 00:00:00 1970 From: Angelo Dureghello Date: Mon, 22 Dec 2014 19:06:51 +0100 Subject: [U-Boot] m68k: Build problems on some boards In-Reply-To: References: <547CD297.4080002@sysam.it> <20141202132613.67DB.AA925319@jp.panasonic.com> <547D84E8.90900@sysam.it> Message-ID: <54985DBB.20409@sysam.it> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Masahiro, On 15/12/2014 17:46, Masahiro YAMADA wrote: > This is a known (and unfortunate) problem. > > The Linux m68k toolchains (as I am using) define size_t as "unsigned > int", whereas bare-metal m68k toolchains (as you are using) define > size_t as "unsigned long". > > People often want to adjust the type definition to the toolchains they > are using. > > Commit ddc94378d changed __kernel_size_t definition from "unsigned > int" to "unsigned long". > > Commit fbe79a17 changed it back to "unsigned int" again. > > > BTW, Linux Kernel has the same problem as we have for U-Boot. > > I posted a question about this to LKML. > > If you are interested in it, check out this thread: > https://lkml.org/lkml/2014/12/15/110 > > > According to that thread, the solution the kernel folks chose > is to always use toolchains configured for Linux. > > > For U-Boot, I think we have two options > > [1] Follow the Linux's way: > Ban bare-metal toolchains and always use kernel.org ones > > [2] Use __SIZE_TYPE__ (or include ) > to support both types of toolchains. Many thanks for the deep analysis and clarifications. For me, it is good we know [1] is compiling properly, so i am fine to adopt the kernel.org 32/64 bit toolchains for m68k development, if the community agree, i can prepare a u.boot m68k wiki page with this information. The discussion for [2] is interesting to me, i am trying to understand the thing properly but i still have some doubts: from my understanding, a bare-metal toolchain should be without libc support (or minimal), so the kernel.org "nolibc" should be considered bare-metal ? If so, could the issue be related to "certain" toolchain only ? Also, i am not understanding, i am comparing now 2 different toolchains: CROSS_COMPILE=/opt/toolchains/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf- /MAKEALL -a m68k compiles with warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat] CROSS_COMPILE=/opt/toolchains/Sourcery_CodeBench_Lite_for_ColdFire_uClinux/bin/m68k-uclinux- ./MAKEALL -a m68k this compiles fine, no warnings But if i look to the of the 2 toolchains, they are exactly the same. So why the compilers expects different definitions of size_t ? Regards, Angelo Dureghello Option [2] would be better of course, could the change to use __SIZE_TYPE__ (or include ) be done in a single place ? What impact it can have for other architectures then ? We can also simply collect in a wiki page for m68k dev this informations, (to use kernel.org, and explain the warning reason). Best Regards Angelo Dureghello > Best Regards > Masahiro Yamada