> > 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. > 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 ... > > 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? > > 2. What is the correct file location for multilibbed targets? For > > s390, I put 32bit libraries to /usr/s390-linux/lib, and 64bit > > libraries to /usr/s390-linux/lib64 (and currently I do the same in > > dpkg-cross) But gcc-3.4 makefiles try to use /usr/s390x-linux/lib64 > > for 64bit libraries. So I have to move files in debian/rules2. Is that > > correct? > > the directory name is tightened to the name you configure gcc > for This looks not to be completely true: I configure in with --build=i386-linux --host=i386-linux --target=s390-linux (and this is mentioned in build logs), but files still get installed into /usr/s390x-linux/lib64. Anyway, it's not difficutl to move the files. An interesting question is what is the "proper" location for them. I believe it's /usr/$(target-alias)/lib64, where $(target-alias) is what dpkg-architecture prints. But s390-linux <-> s390x-linux issue is unclear for me. Probably I should just symlink /usr/s390x-linux to /usr/s390-linux (same for sparc/sparc64), but then another question is where those links should be created and removed. Probably in postinst/postrm of any *-s390-cross package that provides 64 bit stuff ... > . same on sparc, where gcc is configured to sparc64-linux, > defaulting to 32bit. > > > 3. I'm having bad time with gcc-3.4 sparc multilib target. Current > > debian/rules.conf contains code that changes TARGET_ALIAS from > > sparc-linux to sparc64-linux. But this causes unwanted side-effects > > (such as attempts to use 'sparc64-linux-as' instead of > > 'sparc-linux-as' as assembler; that fails because there is no > > 'sparc64-linux-as', so it falls back to 'as'; that also fails because > > 'as' is native and can't process sparc assembler. Also, files go to > > /usr/sparc64-linux/... instead of /usr/sparc-linux/...) If I comment > > out TARGET_ALIAS change, buld fails with > > In file included from ../../src/gcc/libgcc2.c:56: > > ../../src/gcc/libgcc2.h:81: error: no data type for mode `TI' > > ../../src/gcc/libgcc2.h:82: error: no data type for mode `TI' > > make[4]: *** [libgcc/64/_muldi3.o] Error 1 > > Before I go deep into upstream code, I'd love to get some advice from > > somebody who has better understanding of what that means and how > > things work... > > I remember having stopped at the very same point and then found out > about the configury done as above. CC'ed Clint and Ben. Ok, I hope they will reply. Nikita P.S. If I happen to get some free time, I'm thinking of doing a major cleanup and documenting of debian/ dir of gcc source packages. Things seem to be unnesessary compicated currently. Espessially I don't like: - control.m4 in it's current state (it's hardly maintainable) - large number of variables that control what is built (do we really need all those - espessially if noticing the fact that non-default combinations are not tested and most likely don't work properly) - too large separation of native and cross targets - huge command blocks in make targets, with large amount of redudancy (why not move stuff to scripts, use debhelper more intensively, etc?) - complicated and poorly controlled dependences inside debian/ itself (for example, have you noticed that 3.4.2-2 upload has control not regenerated from control.m4, so generated version numbers in deps in uploaded package are 3.4.2-1, not 3.4.2-2?) What do you think of that?