Re: 64 bit compilers for x86-64, ppc, etc.

[Bo Thorsen <bo at suse dot de>]

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
he replied:

(quote)
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 :(
(end quote)

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark