This is the mail archive of the
mailing list for the binutils project.
Re: 64 bit compilers for x86-64, ppc, etc.
- From: Bo Thorsen <bo at suse dot de>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: Ian Lance Taylor <ian at zembu dot com>, Andreas Jaeger <aj at suse dot de>,Peter Bergner <bergner at brule dot borg dot umn dot edu>,Steve Munroe <sjmunroe at us dot ibm dot com>,David Edelsohn <dje at watson dot ibm dot com>, Jan Hubicka <jh at suse dot cz>,Andreas Schwab <schwab at suse dot de>, Michael Matz <matz at suse dot de>,<binutils at sources dot redhat dot com>
- Date: Tue, 23 Apr 2002 11:01:44 +0200 (CEST)
- Subject: Re: 64 bit compilers for x86-64, ppc, etc.
On Tue, 23 Apr 2002, Alan Modra wrote:
> On Tue, Apr 23, 2002 at 09:46:45AM +0200, Bo Thorsen wrote:
> > On Mon, 22 Apr 2002, Andreas Jaeger wrote:
> > > Hi PPC64 and x86-64 developers,
> > >
> > > David contacted me regarding problems configuring GCC for PowerPC64.
> > > I think that the PowerPC64 team has similar problems like we have with
> > > x86-64 and propose to work together to find out what kind of problems
> > > there are and solve them together.
> > >
> > > I propose that we first make a list of the known problems and then
> > > decide how we can taggle this.
> > >
> > > Bo, I think you were the one that encountered most of the problems.
> > > Can you give a first summary of the situation including the known
> > > problems on x86-64?
> > We have two problems that needs fixes that would also benefit other
> > architectures: Multilib and float128.
> > For float128 (128 bit floats, obviously) the problem is that we have set
> > long doubles to also have a sizeof 16 for alignment reasons and gcc
> > identifies a type on it's size. We have to teach gcc to see the difference
> > between the two different types of 16 bytes wide floats.
> > Multilib is a problem we have with other libraries, not the gcc ones. On
> > x86-64 we have a lib/libc.so and lib64/libc.so. When we compile with
> > "gcc -m32 hello.c", it should link to the 32 bit lib and "gcc hello.c"
> > should link with the 64 bit lib. The problem here is that there is
> > currently no other way to do this than specify an absolute link path in
> > linux64.h This means you have no way to link to another libc that you
> > compiled yourself. The problem is the same for all other libraries. This
> > really needs to be fixed correctly so all the multilib architectures can
> > remove these ugly absolute paths.
> Hmm, a suitable -Y path will tell the linker where to look for static
> libraries and startup files, as long as gcc doesn't get in the way
> and add -L/usr/lib -L/lib or somesuch. That won't happen when
> building a cross-compiler, which is effectively what we have
> for --target=powerpc64-linux --host=powerpc-linux. The only problem
> remaining is how to pick up the right shared libs, including those not
> specified on the command line, eg. from DT_NEEDED entries. It seems
> to me that this is really a linker problem and could be solved by
> adding directories to the linker script SEARCH_DIR, or maybe by
> changing -Y to affect the search path for shared libs. Actually,
> changing the behaviour of -Y is rather attractive as it allows gcc
> full control over linker behaviour.
It would be really great if this was all that was needed. I discussed
something like this with Jan Hubicka about a month ago, and this was what
I think it is not the case. I believe gcc.c has hardcoded it's
own algorithm for finding the startup files. (see --print-file feautre)
and that feature does overwrite whatever we do on the binutils side :(
Bo Thorsen | Praestevejen 4
Free software developer | 5290 Marslev
SuSE Labs | Denmark