[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Alignment 2



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