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