[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc-cross-dev details and future plans

On Thu, Dec 18, 2014 at 11:16:34AM +0000, Wookey wrote:
> re gcc-source versioning:
> Dima5: We could also make cross-gcc-dev contain the actual patched gcc
>        source. that would still make its installation set the same size as
>        when it depends on gcc-4.9-source, but it would always be installable

This seems to be wrongly attributed. I said this.

> Interesting idea. That's kind of heading back to the days of
> cross-toolchain-source which seems a bad direction, but if we are
> maintaining a significant patchset on top of gcc-4.9 then it sort-of
> makes sense. Being forced to keep the patches in-sync is almost
> certainly healthier long-term.

Well, of course the cross-gcc source package would still contain only
the patches. It would Build-Depend on gcc-4.9-source to produce a binary
package containing patched sources. Of course this still requires
keeping the patches in sync. It would just be a convenience of the one
installing cross-gcc-dev.

The use is a bit dubious though: Building a cross compiler still
requires exactly matching gcc libraries due to the multiarch version
lock. So when cross-gcc-dev and gcc are out of sync, one could obtain
patched sources but not build them (maybe using snapshot.d.o).

When I suggested this, it was just a thought exercise furthering the
idea of cross-gcc-dev Depending on gcc-4.9-source. (I'm not yet
convinced that this is indeed necessary.)

> So, yes a given gcc is only guaranteed to work with the matching
> version of libgcc1 (According to toolchain engineers, I checked), so
> the dependency really should be '='. We changed this in the
> cross-toolchains. Now in practice it usually will work with some
> nearby versions, so we could be more flexible, but '=' is safe.

Given the situation in sid, something seems wrong here. gcc-4.8 Depends
on libgcc-4.8-dev (>= ...) which Depends on libgcc1 (>= ...). But the
libgcc1 it actually ends up with is the one from gcc-4.9. Cleary,
gcc-4.8 (as packaged in Debian) is not using a nearby libgcc1 version.

So either that toolchain engineer you are referring to is wrong or the
gcc-4.8 package in Debian is quite broken.


Reply to: