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? > > 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. 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. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
