Hi Marcin. Would you consider passing
--enable-poison-system-directories to the cross compiler configure?
This makes the '-Wpoison-system-directories' option available which
warns you if the cross compiler picks up a library or header file from
/usr instead of the cross-build environment.
I'm talking with someone who's looking at using the Linaro compiler
and had a strange error due to picking up the host crtn.o. Having
this warning would of tracked down the problem faster.
-- Michael
I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
verified this by doing objdump on libgcc.a and I see combinations of
16 and 32 bit instructions. So does that mean that the toolchain is
only usable for ARM versions that support Thumb-2?
Thanks,
John
As discussed in the meeting yesterday, CodeSourcery has a few MinGW
patches that I had not merged into Linaro GCC.
I have now investigated these patches, and I'm fairly happy that most
are not necessary for Linaro. They're mainly about interworking with Cygwin.
The one exception is this one:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01214.html
(and even that is primarily a GDB issue).
Andrew
I made a patch for ltrace that adds support for Thumb-2. There's not
much to it, but it allows me to trace applications built for Cortex-A8.
Without it, users will experience this bug:
https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/639796
Unfortunately, it appears that the upstream tree is not well-maintained.
I posted it to the mailing list for the project, but others' patches
have been ignored for many months. However, my post precipitated another
contributor to offer to maintain the package.
I also posted this patch as the proposed solution for the above LP bug,
which should allow Linaro to benefit from the work without worrying
about upstream. In fact, a new version of the package appears to have
been released that includes my patch (0.5.3-2ubuntu6). Please give this
updated package a whirl and let me know if there is more work to be done.
Thoughts? Unless I hear feedback from others, I will assume that this
tool now works for Cortex-A[89] and move on to other tasks.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
(this is for current Toolchain WG members. Sorry if I got anyone
else's hopes up)
We'll soon be coming into some decent dual-core Cortex-A9 boards that
have 1 GB of RAM and a good set of USB ports. I've asked for four of
them with hard drives to go into the data centre for general use.
Would anyone also like one for their desk? Note that you're generally
better off using a data centre board as it's one less thing to
maintain.
-- Michael
Hi
I finally built armel cross compiler packages for Ubuntu 10.04 'Lucid' LTS.
They are available in unsigned APT repository:
deb http://people.canonical.com/~hrw/ubuntu-lucid-armel-cross-compilers/ ./
They are built from Maverick packages:
- binutils-source
- eglibc-source
- gcc-4.4-source
- gcc-4.5-source
- linux-source-2.6.35
- armel-cross-toolchain-base
- gcc-4.4-armel-cross
- gcc-4.5-armel-cross
So they do not give exactly same versions as compilers used in 10.04 - please
remember about it while doing cross builds.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Hi folks
apparently some tool calls "strip" instead of "$triplet-strip" when
cross-building; this is something we shall fix, but it is apparently
corrupting the binaries in some cases:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/615765
It seems the ELF architecture isn't set properly, or so I'm told.
Which component is to blame here? Are we looking at a binutils or a
gcc bug for not being able to set or read enough data that the
architecture mismatch isn't detected? What could we do about it?
Thanks!
--
Loïc Minier
