public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Mittelstaedt <T.Mittelstaedt@cadenas.de>
To: gcc-help@gcc.gnu.org
Cc: Tim Prince <tprince@computer.org>,  brian@dessent.net
Subject: Re: Problem building gcc-4.2.2 on 64-bit ubuntu linux, SUCCESS!!
Date: Thu, 20 Dec 2007 13:33:00 -0000	[thread overview]
Message-ID: <476A7032.2080202@cadenas.de> (raw)
In-Reply-To: <476A08C9.76332F9B@dessent.net>

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
>   

  reply	other threads:[~2007-12-20 13:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-19  9:09 Problem building gcc-4.2.2 on 64-bit ubuntu linux Thomas Mittelstaedt
2007-12-19 12:36 ` John (Eljay) Love-Jensen
2007-12-19 13:34   ` Thomas Mittelstaedt
2007-12-19 14:32     ` Thomas Mittelstaedt
2007-12-19 15:00       ` Kai Ruottu
2007-12-19 15:14         ` Kai Ruottu
2007-12-19 15:03       ` Thomas Mittelstaedt
2007-12-19 16:55         ` Thomas Mittelstaedt
2007-12-20  1:56           ` Tim Prince
2007-12-20  6:17             ` Brian Dessent
2007-12-20 13:33               ` Thomas Mittelstaedt [this message]
2007-12-20  7:21             ` Fabian Cenedese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=476A7032.2080202@cadenas.de \
    --to=t.mittelstaedt@cadenas.de \
    --cc=brian@dessent.net \
    --cc=gcc-help@gcc.gnu.org \
    --cc=tprince@computer.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).