On 04.08.2010 16:55, Ulrich Weigand wrote: > Matthias Klose<d...@ubuntu.com> wrote on 08/02/2010 09:38:49 PM: >> On 02.08.2010 21:12, Ulrich Weigand wrote: >>> Matthias Klose<d...@ubuntu.com> 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 >>> installed from a 4.4.3 build? That will most likely work. >> >> No, gnat (4.4.3) has still to work, if gcc (4.4.4) is already installed. > > OK, where I said "gcc", the same applies also for "gnat", the Ada compiler > driver. The reason for why a 4.4.3 gnat would fail if 4.4.4 gcc is > installed > is that it wouldn't find things like collect2, libgcc, crt*.o etc. Right?
yes >>> But it still seems a bit fragile to me; in general, there's no > guarantee >>> that if you intermix 4.4.4 and 4.4.3 components in that way, everything >>> actually works (that's why they use different directories in the first >>> place). >> >> Then I would need to change this internal path with every source change. > I >> don't see this as fragile as long as it is ensured that we ship with the >> different frontends built from the same patchsets/sources. Note that > further >> restrictions are made by package dependencies. > > 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 components so > that > a compiler built from the 4.4.4 sources and using the new middle-end is > used > together with a libgcc built from the 4.4.3 sources, things will break. libgcc is always built from the sources which get uploaded first. > It seems that this does not actually occur in the usage model you describe, > since you apparently always update the core (libgcc etc.) *first*. I'm not > sure if this is actually guaranteed by the package dependencies though. If > it is, then I don't see any real problems with that approach ... > >>> If you want to have separate packages, a cleaner way would appear to be > to >>> make them fully self-contained, e.g. have them each provide their own >>> driver that can be called separately. >> >> I don't understand that. I don't have a problem with the driver, butwith > the >> compiler (gnat1). Having the packages self-contained creates >> another problem in >> that you get file conflicts for files like collect2, various .o files > etc. > > What I was thinking of is along the lines of having gcc-base-4.4.3 and > gcc-base-4.4.4 packages that hold the base files (crt*o, libgcc, > collect2 ...), > such that you can install *multiple* of the base packages at the same time. > This way you could have a gcc-4.4.4 (depending on gcc-base-4.4.4) and a > gnat-4.4.3 (depending on gcc-base-4.4.3) all installed at the same time. sure, you could have separate packages for subminor versions, and introduce a new dependency package for the minor version (gcc-4.4-defaults), but I don't see how this would help within the context of the distribution. Matthias _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
