Nikita V. Youshchenko writes: > > > After a delay that was longer that I hoped, I continued my work on > > > cross-gcc patches. > > > I'm attaching the results. > > > Gcc-3.3 and gcc-3.4 are now almost in sync. > > > 3.3 builds for all debian linux targets > > > 3.4 still fails for sparc target, but builds for all other debian > > > linux targets. > > > Most of reported issues are fixed. I first wanted to fix all known > > > issues before submitting the patches, but this as usual takes more > > > time than expected, and current status of cross-compiler building is > > > bad (e.g. in my previous patches 'cc1' got lost from packages, etc). > > > > so the current patch should go in? > > I think yes. They are definitly better than what's currently in, and the > only big problem I'm currently aware of is sparc gcc-3.4 issue, I don't > know when I will find a way to fix it. > > 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? > > 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. > > > 1. Some binary packages built from gcc-3.[34] sources, do contain > > > symlinks to files provided by packages they don't depend on. This is > > > on multilib targets - gcc has a symlink for 64bit libgcc and does not > > > depend on lib64gcc1, libstdc++-dev has same relations with > > > lib64stdc++. Isn't that a bug? > > > > no, intended. we don't want to have people depend on 64bit stuff by > > default. and there are rumors about adding multiarch support for > > sarge+1. > > 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 ...
