Multiarch paths and toolchain implications
Ulrich.Weigand at de.ibm.com
Wed Aug 4 15:55:11 BST 2010
Matthias Klose <doko at ubuntu.com> wrote on 08/02/2010 09:38:49 PM:
> On 02.08.2010 21:12, Ulrich Weigand wrote:
> > Matthias Klose<doko at 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
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
> > 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.
> 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
> restrictions are made by package dependencies.
The issues I'm thinking of are things like: suppose the 4.4.4 middle-end
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
a compiler built from the 4.4.4 sources and using the new middle-end is
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
> > 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
> compiler (gnat1). Having the packages self-contained creates
> another problem in
> that you get file conflicts for files like collect2, various .o files
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,
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
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
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
More information about the linaro-toolchain