ix it.
That works, thanks!
Chris
> Original message
> From: Christopher Covington
> Date: 02/26/2015 2:52 AM (GMT+07:00)
> To: linaro-toolchain@lists.linaro.org
> Subject: Debian Multiarch Tuple Style Naming With ABE
>
> Hi,
>
> I recently built with ABE
istopher Covington
Date: 02/26/2015 2:52 AM (GMT+07:00)
To: linaro-toolchain@lists.linaro.org
Subject: Debian Multiarch Tuple Style Naming With ABE
Hi,
I recently built with ABE for the first time. It's pretty slick.
Is there a way to make the vendor string (the "none" in
&
@lists.linaro.org
Subject: Debian Multiarch Tuple Style Naming With ABE
Hi,
I recently built with ABE for the first time. It's pretty slick.
Is there a way to make the vendor string (the "none" in
"arm-none-linux-gnueabihf-*") go away? It breaks my scripts without appeari
Hi,
I recently built with ABE for the first time. It's pretty slick.
Is there a way to make the vendor string (the "none" in
"arm-none-linux-gnueabihf-*") go away? It breaks my scripts without appearing
to add value.
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Cen
ge gcc-arm-linux-gnueabihf but the gdb debugger
> is not in that package.
>
> Therefore, I'm wondering if I should use the Linaro toolchain (which include
> arm-linux-gnueabihf-gdb) or if I should install the Ubuntu gdb-multiarch
> package.
>
> What is the difference betwee
>> What is the difference between gdb-multiarch and arm-linux-gnueabihf-gdb
? Is it better to use gdb-multiarch ?
For Ubuntu hosts from 12.04 onwards, gdb-multiarch is used as gdb client
for debugging. As name indicates it is a common client to any architecture
and not restricted
x27;m wondering if I should use the Linaro toolchain (which
include arm-linux-gnueabihf-gdb) or if I should install the Ubuntu
gdb-multiarch package.
What is the difference between gdb-multiarch and arm-linux-gnueabihf-gdb ?
Is it better to use gdb-multiarch ?
;s
>> on offer.
The initial use case would be to build a root filesystem with dynamically
linked executables from the various binary interfaces and architectures
happily finding their correct linker/loader, libraries, etc. A multiarch
layout on the target filesystem may not be the only way to m
On 5 February 2013 22:20, Wookey wrote:
> +++ Christopher Covington [2013-02-05 08:58 -0500]:
>> Hi,
>>
>> It seems to me that your current toolchain releases [1] don't default to a
>> multiarch layout. Am I looking in the right place? Do you anticipate enablin
+++ Christopher Covington [2013-02-05 08:58 -0500]:
> Hi,
>
> It seems to me that your current toolchain releases [1] don't default to a
> multiarch layout. Am I looking in the right place? Do you anticipate enabling
> multiarch in the future? Is doing this currently block
Hi,
It seems to me that your current toolchain releases [1] don't default to a
multiarch layout. Am I looking in the right place? Do you anticipate enabling
multiarch in the future? Is doing this currently blocked by limitations in
tools such as crosstool-ng?
1. http://releases.linaro.org/
Konstantinos, Loïc, and I talked last night about multiarch. Linaro
want multiarch and will use it in all our products and hence need to
get it upstream. There's another meeting in a week to figure out
what's next.
I've written a page on the uses, issues, and his
Matthias Klose wrote:
> On 04.08.2010 16:55, Ulrich Weigand wrote:
> > The issues I'm thinking of are things like: suppose the 4.4.4
middle-end
> > adds code that generates calls to some new libgcc library function,
which
> > itself was added with the 4.4.4 libgcc. If you now mix-and-match
compon
On 04.08.2010 16:55, Ulrich Weigand wrote:
> Matthias Klose wrote on 08/02/2010 09:38:49 PM:
>> On 02.08.2010 21:12, Ulrich Weigand wrote:
>>> Matthias Klose wrote on 08/02/2010 06:25:58 PM:
>>> So the problem that is you want to support a setup where a "gcc" driver
>>> installed from a 4.4.4 bu
Matthias Klose wrote on 08/02/2010 09:38:49 PM:
> On 02.08.2010 21:12, Ulrich Weigand wrote:
> > Matthias Klose wrote on 08/02/2010 06:25:58 PM:
> > So the problem that is you want to support a setup where a "gcc" driver
> > installed from a 4.4.4 build can still call and run a "gnat1" binary
> >
Wookey wrote on 08/02/2010 10:40:23 PM:
> Hope that's not considered rude, Ulrich. (great bit of work capturing
> all that good stuff - thank you).
No problem, that's fine with me. Thanks!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3
Andrew Stubbs wrote:
> I suggest teaching the kernel to rewrite that path when it finds a
> non-existent interpreter. Presumably the kernel can "know" what
> multiarch corresponds to the traditional ABI for any given ELF flags.
The problem with this is that is this brings na
On 02/08/10 20:16, Ulrich Weigand wrote:
> Now this point is where the suggestion to use something like a bind mount
> on startup comes in. That way, there would be no violation of the
> multiarch rules, because /lib/ld.so.1 would not be part of any package,
> and in fact not even
On Mon, Aug 02, 2010, Wookey wrote:
> > https://wiki.linaro.org/WorkingGroups/ToolChain/MultiarchPaths
> http://wiki.debian.org/Multiarch/Spec
> (and deleted the original so we don't get two diverging versions).
I've added a redirect so that people reading the list archive
to other interested parties from the more
neutral ground of Debian), I've moved it to
http://wiki.debian.org/Multiarch/Spec
(and deleted the original so we don't get two diverging versions).
Hope that's not considered rude, Ulrich. (great bit of work capturing
all that good stuff - tha
On 02.08.2010 21:12, Ulrich Weigand wrote:
> Matthias Klose wrote on 08/02/2010 06:25:58 PM:
>
>> this is no "cheating". It makes the packages robust. Remember that some
>> frontends are built from different source packages and that a
>> gnat-4.4 (4.4.4) still needs to be buildable with a gnat-4.
Loïc Minier wrote:
> > If we have to install different native versions of the clever wrapper,
> > we might just as well install the original native ELF interpreters --
> > that's neither better nor worse from a multiarch rules perspective.
>
> Hmm right; doesn'
Matthias Klose wrote on 08/02/2010 06:25:58 PM:
> this is no "cheating". It makes the packages robust. Remember that some
> frontends are built from different source packages and that a
> gnat-4.4 (4.4.4) still needs to be buildable with a gnat-4.4 (4.4.3)
> and an already updated gcc-4.4 (4.4.4
e that. However, this means that we've once again violated
> multiarch rules ...
Oh absolutely, it would be native to the current architecture of the
kernel, and would be installed in a multiarch directory too.
> If we have to install different native versions of the clever wrapper,
&g
(minor) symlink. This doesn't really
>> relate to the multiarch topic, but it reminds me that we ought to fix
>> the distro divergences so that it's easier to swap an upstream
>> toolchain with a Debian/Ubuntu one and vice-versa.
>
> Agreed. Not sure what this p
Loïc Minier wrote:
> > I understood you to propose an alternative solution that would keep the
> > old ELF interpreter name (/lib/ld.so.1) embedded in executables, and
> > keep them working by installing some "common" loader at this location.
>
> Ah no, I inten
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> Maybe I misunderstood something else about your point then, so let's try
> and take a step back. Today, the location of the ELF loader is embedded
> into the executable itself, using a full pathname like /lib/ld.so.1.
> In a mult
h will load and emulate the ELF loader for the emulated
> arch in the other cases.
Maybe I misunderstood something else about your point then, so let's try
and take a step back. Today, the location of the ELF loader is embedded
into the executable itself, using a full pathname like /lib/ld
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> Agreed. Not sure what this particular divergence helps ...
So Matthias mentionned that gnat and gcc are not always using the same
minor version, and so it helps bootstrap them to have the common bits
installable without overly strict dependencies.
Andrew Stubbs wrote:
> It is buried a little deep, but it is there. I guess I'd like to see a
> flow of how a binary loads libraries:
>
> 1. User launches binary.
>
> 2. Kernel selects a suitable execution environment (native/qemu).
>
> 3. Kernel reads .interp an
iants are desired,
>they can be build just as today, only under the (same) multiarch
>suffix. They could be packaged either within a single pacakge,
>or else using multiple packages (of the same multiarch type).
>
> If you feel this could be made clearer, I'd ap
ad, and we
> have a $(version) -> $(major).$(minor) symlink. This doesn't really
> relate to the multiarch topic, but it reminds me that we ought to fix
> the distro divergences so that it's easier to swap an upstream
> toolchain with a Debian/Ubuntu one and vice-v
Andrew Stubbs wrote on 08/02/2010 01:35:01 PM:
> On 31/07/10 19:01, Ulrich Weigand wrote:
> > I've finally completed a first of draft the write-up of toolchain
> > implications of multiarch paths that we discussed in Prague. Sorry it
took
> > a while, but it got a
On 31/07/10 19:01, Ulrich Weigand wrote:
> I've finally completed a first of draft the write-up of toolchain
> implications of multiarch paths that we discussed in Prague. Sorry it took
> a while, but it got a lot longer than I expected :-/
>
> I'd appreciate any feedb
(minor) instead, and we
have a $(version) -> $(major).$(minor) symlink. This doesn't really
relate to the multiarch topic, but it reminds me that we ought to fix
the distro divergences so that it's easier to swap an upstream
toolchain with a Debian/Ubuntu one and vice-versa.
I don&#x
Hi Wookey,
I've finally completed a first of draft the write-up of toolchain
implications of multiarch paths that we discussed in Prague. Sorry it took
a while, but it got a lot longer than I expected :-/
I'd appreciate any feedback and comments!
Multiarch paths and toolchain im
36 matches
Mail list logo
