> > 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 Conflicts:/Replaces:/Provices: cpp-x.y) > > 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 information)?
