Re: [MiNT] Alignment 2

[Vincent Rivière <vincent.riviere@freesbee.fr>]

MiKRO wrote:
> (btw any progress in 
> your research about multi versions of libiberty (if I remember it right) 
> ? )

That libiberty stuff seems to disrupt you :-)

The problem is still here in GCC 4.2.3.

You can rollback the libiberty patch by replacing, in the GCC root 
directory, the files configure and configure.in by the original ones.

The useful part of the patch is in configure.in
+  m68k-*-mint*)
+    noconfigdirs="$noconfigdirs target-libiberty ${libgcj}"
+    ;;

I regenerated the configure file, that 3 lines were inserted as 
expected. But because the next line numbers have shifted, the line 
information in the next error messages have been modified. That's the 
explanation of the multiple lines like this in the configure patch.
-echo "configure:1866: checking for $ac_word" >&5
+echo "configure:1869: checking for $ac_word" >&5

So what happens without the libiberty patch ?
The first part "make all-gcc" works fine.
Then the Makefile tries to compile all the target libraries for the 
different multilib versions. The first one is libiberty.
Unfortunately, the libiberty makefile doesn't use automake (which is 
bug-free and used by the other libraries)
Because of the bug, the configure script messes up the multilib options.
For example, the file m68k-atari-mint/mshort/libiberty/config.h
contains that obvious wrong line:
#define SIZEOF_INT 4

The problem become visible with the error:
fibheap.h:66: error: width of 'degree' exceeds its type

Furthermore it seems that there is another bug.
Things are different if make is typed from the top level directory or if 
make is typed in the m68k-atari-mint/mshort/libiberty folder.
In the latter case, the option -mshort is not passed to gcc !
Of course, it will not complain, but without -mshort and with 
SIZEOF_INT=4, the library will not be -mshort at all !

When I discovered that, I choosed to avoid all that problems by 
disabling the build of the target libiberty (the one which would be 
installed near libsupc++.a, libstdc++.a and libssp.a).
That is not a problem, because that library is usually packaged with the 
packages dependent of it (like GCC itself, or the binutils), so the 
installed version is mostly useless.
Of course, it would be better to fix the configure files, but everyone 
knows it is a bit complicated.

That's all.

--
Vincent Rivière