Re: cross-gcc patches
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
Reply to: