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

Re: cross-gcc patches



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 ...



Reply to: