Hi,
I'm trying to build the native compiler to a arm a9 using this tutorial,https://wiki.linaro.org/WorkingGroups/ToolChain/Using/GCCNative.Ho…, I need to compile in a x86_64 platform ubuntu, like this --target=arm-unknown-eabi --build=i686-pc-linux-gnu --host=arm-unknown-eabi, but without success.There is any possible solution?
Thank you.Felipe Rocha da Rosa.
Hi all,
We are using Linaro 13.03 toolchain(gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to execute a simple test code to check whether ARM assembly code executes on board or not. Execution is on Arndale Board. Every time We include assembly function, We get segmentation fault. Kindly check if I We are missing any arm related flags in makefile.
We have attached the 'helloworld' test code and makefile.
Regards,
Vishwa
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
If your code is sensitive to the size of long long, can you use the predefine:
__SIZEOF_LONG_LONG__
If that doesn't work, then you can use:
gcc -dM -E - < /dev/null
to tell you what predefines a gcc compiler has (I would probably look for predefines more specific to what your code is sensitive to than look for a particular compiler).
I also wonder a little about your original problem statement since "%lld" should be a way to always print "long long" and if you have a matched set of compiler and library, then it should adjust both together. If you are using "%ld" instead, this works in situations where "long" is the same size as "long long" but may not work when these are different sizes.
--mev, Mike Vermeulen
Hi there!
On Linaro gcc 4.6, I am facing an issue due to "long long" integers
not being 64 bit as they are on other platforms I'm targeting,
which causes different issues, most importantly with printf format
strings. I am now circumventing these by using the C/C++ preprocessor
in order to choose the right format strings. In order to minimize the
necessity for users to manually configure things, I'm wondering if
there is a way to detect the Linaro gcc compiler through preprocessor
macros. Is this possible?
Thanks.
Best regards,
Isidor
Hi all,
We are using Linaro 13.03 toolchain(
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to
execute a simple test code to check whether ARM assembly code executes on
board or not. Execution is on Arndale Board. Every time We include assembly
function, We get segmentation fault. Kindly check if I We are missing any
arm related flags in makefile.
We have attached the ‘helloworld’ test code and makefile.
Regards,
Vishwa
Is that supposed to be possible? When I add --disable-multilib to the
configure options, the build fails on the install, because it hasn't built
any of src/gcc-linaro-4.8-2014.02/libgcc:
/bin/sh ../../../../src/gcc-linaro-4.8-2014.02/libgcc/../mkinstalldirs
/home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3
/usr/bin/install -c -m 644 libgcc_eh.a
/home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3/
/usr/bin/install: cannot stat `libgcc_eh.a': No such file or directory
make[3]: *** [install-shared] Error 1
make[3]: Leaving directory
`/home/ubuntu/work483/build/gcc/arm-linux-gnueabi/libgcc'
make[2]: *** [install-target-libgcc] Error 2
make[2]: Leaving directory `/home/ubuntu/work483/build/gcc'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/ubuntu/work483/build/gcc'
make: *** [stamp/gcc-install] Error 2
I don't want or need multilib, so I'd rather build the toolchain without
it, but before I try to make that happen, I wanted to make sure it's
supposed to be able to get built correctly that way.
Thanks,
Diane
== Progress ==
* IAS (TCWG-377)
- Long discussions about magic in inline asm
- Bottomline is: we're still validating anyway
* AArch64 (TCWG-387)
- Making it build with CMake, discarding some tests
- Similar changes to the test-suite
- All green except sphereflake
* Buildbots
- Investigating one failure on test-suite due
to register allocator changes
- Will continue this during or after Connect
* Background
- Connect preparations
- EuroLLVM 14 sync call, paper discussions
- Researching some kernel C/ASM syntax
- Studying __builtin_constant_p usage
- Patch reviews, etc.
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Connect
(slightly delayed)
== Progress ==
* 3 day week (annual leave Thursday and Friday)
* QEMU ARMv8 CRC instructions (4/10, TCWG-52)
* Slides for Connect (1/10)
* Further work on longjmp/setjmp Systemtap probes on ARM (1/10, TCWG-378)
== Issues ==
* None
== Plan ==
* Complete QEMU CRC instruction work
* Preparation for Connect
--
Will Newton
Toolchain Working Group, Linaro
== This week ==
- US Holiday on Monday, January 17th
- Backported 202407 - Fix parameter to vrsqte_f64
- Backported 202259 (on read/write branch) - AARCH64, fix return types
for vaddvq_s64, vaaddvq_u64
- Backported 202321 - Fix vdup<bhsd>_lane<q>_* instrinsics' lane parameter
- Backported 202322 - Fox register constraints for lane intrinsics
- Installed Qemu64 simulator and attempted to test aarch64 backports.
- Shared library issue is preventing qemu64 from executing; Rob Savoy
is investigating
== Next week ==
- Test pending git review backports with Qemu64 if issues resolved
- Test backports completed this week on Qemu64
- New backports
== Future ==
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org