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

[Alan Modra <amodra at bigpond dot net dot au>]

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.

The patch is a one-liner, but I'd like some comment from a linker
guru as to whether this is advisable.  Ian?

ld/ChangeLog
	* lexsup.c (set_default_dirlist): Behave as if -Y paths were
	not specified on the command line, ie. affect shared lib
	search path.

Index: ld/lexsup.c
===================================================================
RCS file: /cvs/src/src/ld/lexsup.c,v
retrieving revision 1.48
diff -u -p -r1.48 lexsup.c
--- ld/lexsup.c	11 Feb 2002 02:41:37 -0000	1.48
+++ ld/lexsup.c	23 Apr 2002 08:08:28 -0000
@@ -1150,7 +1150,7 @@ set_default_dirlist (dirlist_ptr)
       if (p != NULL)
 	*p = '\0';
       if (*dirlist_ptr != '\0')
-	ldfile_add_library_path (dirlist_ptr, true);
+	ldfile_add_library_path (dirlist_ptr, false);
       if (p == NULL)
 	break;
       dirlist_ptr = p + 1;

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre