Re: cross-gcc patches
> > Btw, what's the current situation with sarge packages? I see binutils
> > 2.15-4 migrated to sarge recently - does that mean that a new upload
> > of gcc-3.3 and gcc-3.4 will happen? If so, please let me know, and
> > give me a chance to backport last cross-targets fixes to sarge
> > versions before the upload, to make sarge gcc packages to build for
> > cross targets with sarge version of dpkg-cross, etc.. I believe this
> > may be done very quickly (a day or two, most of that time to test
> > builds), and changes will not affect native building.
> dpkg-cross is the same in testing and unstable. which tools you depend
> on are at different versions?
But sarge version of gcc source package still uses old way of handling
cross-strips (one from dpkg-cross 1.16 or so), and won't build with
dpkg-cross >= 1.18. Old way of cross-strip handling was removed from
dpkg-cross while resolving a RC issue (see #265620).
Also, I'd like to see all those recent fixes in sarge (e.g. having properly
installed link to libgss_s.so in gcc-lib to enable cross build of shared
libraries) - if that's at all possible.
So the question is - is it possible to get fixes in sarge? If yes, I'll
make and test a backport. If no, I'll spend my time for other tasks :).
> > > why do you separate out cpp? is for symmetry reasons with the native
> > > packages?
> > Mostly because you do the same in native compilers (but also because
> > some scripts and users expect $target-alias)-cpp to be available). My
> > plan is to make cross-targets differ from native target as little as
> > possible, and then merge rules.d/binary-%-cross.mk files into
> > rules.d/binary-%.mk files. Looks that if done properly, that will not
> > add much noise to rules.d/binary-%.mk. I hope this will help to avoid
> > de-synchronization of native and cross targets, that already caused
> > several failures since I started to maintain cross targets.
> > Btw, is there any rationale to have separate cpp and gcc binary
> > packages even for native targets? Looks actual compiler binary (cc1)
> > is now in cpp package, gcc package provides only a small whapper in
> > /usr/bin ...
> yes, /lib/cpp. There is no other reason.
This may be provided by gcc-x.y package (together with
> > Adding 'proper' dependences (for lib64gcc and lib64stdc++) will just
> > bring in several library packages. I don't think that 1-2 several
> > megabytes of disk space is an issue on machines that people use for
> > development. And adding such dependences will avoid dead links (and
> > failures of running gcc -m64 with non-intuitive error messages). I
> > don't think this will hurt anyone.
> > And if you don't want to add dependences, maybe there should be
> > Recommends: or Suggests:, and a proper comment in package
> > descriptions?
> hmm, it sucks in ia32-libs ...
Could you please provide a bit detail (or point me to appropriate