gcc-4.4 cross build for m68k on i486 fails

[Eric]

Binary package hint: gcc-4.4

gcc-4.4 cross build for m68k on i486 fails due to:

"checking for suffix of object files... configure: error: in `/home/eric/src/m68k-cross-compiler/gcc-4.4-4.4.1/build/m68k-linux-gnu/m68040/libgcc':
configure: error: cannot compute suffix of object files: cannot compile"

Upon further inspection, config.log states:

"xgcc: Internal error: no multiarch mapping for multilib (m68040)"

The internel error originates from set_multiarch_dir() in src/gcc/gcc.c:7854 where some input is checked against a fairly small array of multilib combinations, none of which include m68k.

The build procedure closely followed http://wiki.debian.org/BuildingCrossCompilers. The commands were:

apt-get source gcc-4.4 && cd gcc-4.4-4.4.1 && export ARCH=m68k && export GCC_TARGET=$ARCH && debian/rules control && dpkg-buildpackage -us -uc -rfakeroot -b -d

The release is karmic.

[Matthias Klose (doko)]

try playing around with the multiarch settings in debian/rules.defs and debian/rules2

[Thorsten Glaser (mirabilos)]

same for a native build of gcc-4.4_4.4.3-7_m68k on Debian unstable/m68k FWIW

[Thorsten Glaser (mirabilos)]

I may have a patch. I’ll tell you in some 3‥4 days whether it worked… ☺

[Thorsten Glaser (mirabilos)]

It doesn’t quite work right yet…

[Thorsten Glaser (mirabilos)]

… but this is the patch I used.

• fix multilib configuration

But libgfortran cannot be built multilib because one of the system includes contains
inline assembly that is invalid with -mfidoa (but we could probably tell gcc which
multilib configurations to use… maybe just m68k and coldfire?).

• disable multiarch and multilib

Now libstdc++ missing symbols are a problem, but I suppose the rest can be built.

[Matthias Klose (doko)]

- multiarch shouldn't be disabled
- the selection which multilibs to build should be done by patching gcc/config/m68k/*

[Thorsten Glaser (mirabilos)]

Thanks, but there’s still the issue of the C++ symbols, do you have any idea about
what happens there, whether it’s important, how to fix it, etc?

[Matthias Klose (doko)]

see libstdc++-v3/src/mutex.cc:

#ifdef _GLIBCXX_HAVE_TLS
  __thread void* __once_callable;
  __thread void (*__once_call)();

and find out why it is configured not to have _GLIBCXX_HAVE_TLS defined.

Or you comment out this symbol for first set of test packages.

[Thorsten Glaser (mirabilos)]

Easy, TLS for m68k needs gcc-4.5 and probably eglibc-2.12 (although a 2.11 backport, to make it
in time for squeeze, is in the works, AFAIHH on debian-68k@).

Any chance to get gcc-4.4 without TLS for m68k into unstable?

[Matthias Klose (doko)]

closing the Ubuntu task as won't fix. The packaging did see vast changes, so it may be possible that it does build, but I don't want to track is as an Ubuntu task.

[Thorsten Glaser (mirabilos)]

For the record: I’m working on gcc-4.4 in Debian, and we’ve got something that *almost*
works (there’s still a bug in the backported TLS support, and one of the m68k patches
doesn’t apply as it’s in the gcc-4.4 source package from the unstable archive).

If you need to build a gcc-4.4 for m68k at the moment, contact me (I also have appropriate
eglibc packages and linux kernel headers, but can/will not upload them before the TLS
transition is finished, as to not make the archive even _more_ uninstallable).

[Thorsten Glaser (mirabilos)]

A fixed version of gcc-4.4 was uploaded to Debian unstable.

Uploader: Thorsten Glaser (no PGP/MIME please, use Inline OpenPGP instead) <email address hidden>
Host: debian-ports.org
Accepted: gcc-4.4_4.4.5-7_m68k.changes

[Thorsten Glaser (mirabilos)]

FWIW, I got bored. Now that stuff is uploaded to Debian, I made a cross toolchain (on sid):

# cross-compile from amd64 to m68k
deb http://people.debian.org/~tg/f sid cross-m68k

http://people.debian.org/~tg/f/debidx.htm → overview of contained packages

This is most likely a one-time-only thing though. I don’t believe in cross-compiling.
Things worked mostly fine though. The *_all.deb you need to compile this on i386
are included.