From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27107 invoked by alias); 20 Dec 2007 13:33:11 -0000 Received: (qmail 27094 invoked by uid 22791); 20 Dec 2007 13:33:09 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.cadenas.de (HELO cnsbw01.cadenas.de) (213.179.137.23) by sourceware.org (qpsmtpd/0.31) with SMTP; Thu, 20 Dec 2007 13:32:57 +0000 Message-ID: <476A7032.2080202@cadenas.de> Date: Thu, 20 Dec 2007 13:33:00 -0000 From: Thomas Mittelstaedt User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gcc-help@gcc.gnu.org CC: Tim Prince , brian@dessent.net Subject: Re: Problem building gcc-4.2.2 on 64-bit ubuntu linux, SUCCESS!! References: <4768E104.2000801@cadenas.de> <47691F4A.4010607@cadenas.de> <47692CD3.7040708@cadenas.de> <4769342E.2020004@cadenas.de> <47694E5D.10207@cadenas.de> <4769CBC8.8060705@computer.org> <476A08C9.76332F9B@dessent.net> In-Reply-To: <476A08C9.76332F9B@dessent.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00363.txt.bz2 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: > 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 >