This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
(Added Alexey Neyman, who did the multilib work) > On May 18, 2016, at 5:33 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > > Hi Bryan, > > On Tue, May 17, 2016 at 3:50 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: >> >>> On May 17, 2016, at 6:19 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >>> >>> Hi, >>> >>> In 2014 there has been some work on multilib support in crosstool-ng, >>> by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail >>> threads [1] and [2]. >>> >>> It looks as if this work has not been integrated in crosstool-ng. >>> Meanwhile also the bitbucket branch referenced in the threads no >>> longer exists and I can't find the corresponding branches on github. >>> >>> What is the latest state of this work? >>> Where are the latest patches? >>> What are the remaining problems? >>> >>> I'm currently interested in a multilib toolchain 32/64 bit for >>> Freescale e6500 processors. >>> I ported one of Cody's patches to crosstool-ng 1.22.0 and the build >>> advanced a bit further than with the 1.22.0 baseline, but now breaks >>> at the 'pass-2 core C gcc compiler' step. >>> >>> Thanks, >>> Thomas >>> >>> [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html >>> [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html >> >> See here: https://github.com/crosstool-ng/crosstool-ng/pull/383 >> >> Please test and review. Alexey, could you help out with this one? > > Interesting, thanks! > > I created a toolchain based on that PR with the following configuration: > > CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" > CT_ARCH_CPU="e6500" > CT_ARCH_64=y > CT_ARCH_powerpc=y > CT_MULTILIB=y > CT_KERNEL_linux=y > CT_KERNEL_V_3_18=y > CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_V_4_9_3=y > CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" > CT_CC_LANG_CXX=y > > The idea is that 32-bit should be the default, without requiring > additional options on the compiler command-line. > > When passing this toolchain to buildroot, applications seems to build > fine in 32-bit (I did not try to run them yet). > The kernel is also correctly built in 64-bit. > However, there is something wrong for u-boot. I get errors like: > > /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: > Relocatable linking with relocations from format elf32-powerpc > (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc > (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported > > which indicates that the default format used by ld.bfd is 64-bit > rather than 32-bit. If I manually replay this command-line with the > additional -m elf32ppc, it seems to work correctly and a 32-bit > builtin.o is created. > > What am I missing? Why is ld not taking 32-bit as default, while gcc is? > > (I did not post to the github PR because it may all be caused by a > misconfiguration or misunderstanding on my part). > > Thanks, > Thomas
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |