Chen, Wookey,
Thanks for the responses.
On 02/05/2013 08:55 PM, Zhenqiang Chen wrote:
> On 5 February 2013 22:20, Wookey wrote:
>> What is your use-case? Knowing that will help us advice on best course
>> of current action and inform us on how we might need to change what's
>> on offer.
The ini
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 enabling
>> multiarch in the future? Is doin
+++ 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 blocked by limitations in
> to
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 namespace policy into
t
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 part of any file
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 archives can
follow the link
+++ Ulrich Weigand [2010-08-02 16:13 +0200]:
> > We should post it on the Linaro wiki, probably.
>
> It's now on:
> https://wiki.linaro.org/WorkingGroups/ToolChain/MultiarchPaths
As this is actually a much wider issue than just Linaro, (and because
it is better presented to other interested parti
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't give us anything more
OK, then we
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
On Mon, Aug 02, 2010, Ulrich Weigand wrote:
> So now we get back to my original question: what file type would that
> "clever wrapper" be? The kernel can only load an ELF interpreter that is
> itself an ELF file of the native architecture, so that wrapper would
> have to be that. However, this me
On 02.08.2010 14:00, Ulrich Weigand wrote:
> Loïc Minier wrote:
>> and I think
>> Debian/Ubuntu toolchains cheat in some areas; for some directories
>> which would use $(version) we use $(major).$(minor) instead, and we
>> have a $(version) -> $(major).$(minor) symlink. This doesn't real
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 intended us to move to /lib/$(multiarch)
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 multiarch world, this pathn
Loïc Minier wrote on 08/02/2010 05:30:05 PM:
> > > or more elegantly we could
> > > have a generic loader which checks the architecture of the target
ELF
> > > file before calling the arch-specific loader. This loader would be
> > > linked to from all the old locations.
> >
> > Well, but the
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 and loads the multiarch dynamic link
On 02/08/10 12:46, Ulrich Weigand wrote:
> The second half of the section "Loading/running an executable" is about
> thw HWCAP stuff (look for "capability suffix"). In the summary I have
> this point:
>
> * If capability-optimized ISA/ABI-compatible library variants are desired,
>they can be b
Loïc Minier wrote:
> Awesome analysis!
Thanks!
> So I think you analyzed the upstream toolchain behavior
Yes, that's true.
> and I think
> Debian/Ubuntu toolchains cheat in some areas; for some directories
> which would use $(version) we use $(major).$(minor) instead, and we
> have a $(
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 lot longer than I expected :-/
>
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 feedback and comments!
Thanks Ulr
Awesome analysis!
On Sat, Jul 31, 2010, Ulrich Weigand wrote:
> $(version)
> GCC version number
So I think you analyzed the upstream toolchain behavior, and I think
Debian/Ubuntu toolchains cheat in some areas; for some directories
which would use $(version) we use $(major).$(minor) ins
26 matches
Mail list logo
