Thank you for the hint, Brian
Now it compiles to the finish and works (builds small test program,
builds binutils 2.18),
but I had to change line 172 in libmudflap/mf-runtime.c
from
uintptr_t __mf_lc_mask = LOOKUP_CACHE_MASK_DFL;
to
__mf_uintptr_t __mf_lc_mask = LOOKUP_CACHE_MASK_DFL;
so that it corresponds with the decl in the header file, but get lots of
warnings now:
/bin/sh ./libtool --mode=compile /localbuild/gcc-build/./gcc/xgcc
-B/localbuild/gcc-build/./gcc/
-B/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/bin/
-B/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/lib/ -isystem
/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/include -isystem
/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.2.2/libmudflap -I. -Wall -ffunction-sections
-fdata-sections -I/usr/include/i486-linux-gnu/ -DLIBMUDFLAPTH -c
../../../gcc-4.2.2/libmudflap/mf-hooks2.c -o pth/mf-hooks2.lo
/localbuild/gcc-build/./gcc/xgcc -B/localbuild/gcc-build/./gcc/
-B/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/bin/
-B/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/lib/ -isystem
/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/include -isystem
/opt/gcc-4.2.2/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.2.2/libmudflap -I. -Wall -ffunction-sections
-fdata-sections -I/usr/include/i486-linux-gnu/ -DLIBMUDFLAPTH -c
../../../gcc-4.2.2/libmudflap/mf-hooks2.c -fPIC -DPIC -o
pth/.libs/mf-hooks2.o
../../../gcc-4.2.2/libmudflap/mf-hooks2.c: In function '__mfwrap_memcpy':
../../../gcc-4.2.2/libmudflap/mf-hooks2.c:137: warning: cast from
pointer to integer of different size
../../../gcc-4.2.2/libmudflap/mf-hooks2.c:137: warning: cast from
pointer to integer of different size
../../../gcc-4.2.2/libmudflap/mf-hooks2.c:137: warning: cast from
pointer to integer of different size
../../../gcc-4.2.2/libmudflap/mf-hooks2.c:137: warning: cast from
pointer to integer of different size
I also had to adjust files in the installation, since the installed gcc
complained about gcc_s.so not been found when linking:
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ mv lib32/libiberty.a
lib/gcc/x86_64-unknown-linux-gnu/lib
lib32/ lib64/
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ mv lib32/libiberty.a
lib/gcc/x86_64-unknown-linux-gnu/lib32/
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ mv lib64/libiberty.a
lib/gcc/x86_64-unknown-linux-gnu/lib64/
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ pwd
/opt/gcc-4.2.2
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ mv lib32/ lib32.bak
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ mv lib64/ lib64.bak
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ ln -s
lib/gcc/x86_64-unknown-linux-gnu/lib32/ lib32
tmstaedt@buildlnx2:/opt/gcc-4.2.2$ ln -s
lib/gcc/x86_64-unknown-linux-gnu/lib64/ lib64
===========================
tmstaedt@buildlnx2:/localbuild/gcc-4.2.2/gcc/config/i386$ diff
t-linux64.orig t-linux64
6a7,13
> # On Debian, Ubuntu and other derivitive distributions, the 32bit
libraries
> # are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are
symlinks to
> # /lib and /usr/lib, while other distributions install libraries into
/lib64
> # and /usr/lib64. The LSB does not enforce the use of /lib64 and
/usr/lib64,
> # it doesn't tell anything about the 32bit libraries on those
systems. Set
> # MULTILIB_OSDIRNAMES according to what is found on the target.
>
9c16
< MULTILIB_OSDIRNAMES = ../lib64 ../lib
---
> MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo
$(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
15c22,23
< crtbeginT.o crtfastmath.o
---
> crtbeginT.o \
> crtfastmath.o
17,21c25,26
< # The pushl in CTOR initialization interferes with frame pointer
elimination.
< # crtend*.o cannot be compiled without -fno-asynchronous-unwind-tables,
< # because then __FRAME_END__ might not be the last thing in .eh_frame
< # section.
< CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer
-fno-asynchronous-unwind-tables
---
> softfp_wrap_start := '\#ifdef __x86_64__'
> softfp_wrap_end := '\#endif'
tmstaedt@buildlnx2:/localbuild/gcc-4.2.2/gcc/config/i386$
Brian Dessent schrieb:
Tim Prince wrote:
Ubuntu decided to find a 64- vs 32- bit setup incompatible with
predecessor distros.
Not just Ubuntu, but Debian (and anything based on Debian.) You make it
out to seem like the Debian maintainers did this because they just felt
like being different, but I'm sure they had their own good reasons.
After all, they had to maintain a local patch in their gcc trees to make
it work, so it's not like they didn't also feel the burden of this. If
the distro maintainers thought that the tradeoff of making tens of
thousands of packages easier for their team of maintainers to manage
warrants a two line change in some gcc configury, then that's their
right.
Presumably, there is an ubuntu patch set for this,
but it's quite inconvenient that they chose to break the scheme chosen
by their predecessors. The scheme chosen by everyone else is to put the
64-bit stuff in /usr/lib64, and the 32-bit stuff in /usr/lib.
The patch to make this alternative layout work has been in mainline gcc
for more than 2 months:
<http://gcc.gnu.org/viewcvs?view=rev&revision=128845> so the issue is
now moot, or at least it will be before too long.
Pretty
much the kind of mess Bill Gates wanted to see the alternatives get into.
And this is relevant how?!? Yes, it sure does suck that you can't
install gcc in Debian. Oh wait, you can: "apt-get install gcc".
The fact that Debian maintainers go out of their way to modify and
"Debianize" many software packages sometimes does mean that occasionally
patches are required to get upstream sources to work. This is a feature
not a bug, and it's one of the reasons why I happen to cherish Debian
based systems above all others. If you want something that's just a
bunch of software thrown together without any patches (= without any
cohesion), by all means run far and fast from Debian; it will drive you
crazy.
Brian
