Nikita V. Youshchenko writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello. > > 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? why do you separate out cpp? is for symmetry reasons with the native packages? > I also have some questions. Probably I should ask somewhere else, in this > case please tell me where to forward the questions. hmm, good question, I don't know where. debian-toolchain is still dead. > 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. > 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. 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. Matthias