This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: AIX shared library support and GCC PIC libraries
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: AIX shared library support and GCC PIC libraries
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Fri, 05 May 2000 12:42:05 -0600
- cc: gcc-patches at gcc dot gnu dot org, Geoff Keating <geoffk at cygnus dot com>
- Reply-To: law at cygnus dot com
In message <200005022305.TAA23314@mal-ach.watson.ibm.com>you write:
> With a really good piece of insight from Geoff Keating, I now have
> a set of patches to automatically build proper AIX shared libraries as
> part of the GCC target library generation process when --enable-shared=yes
> is requested. A limitation which I was trying to overcome is GCC equates
> special PIC object files with shared libraries, but all AIX code is
> position independent with no need for separate PICFLAG and "pic" diectory.
>
> Geoff pointed out that a pic subdirectory only is needed if
> PICFLAG is defined; otherwise, the object files must be identical for the
> two cases. This lead to the decision that only configure.in and friends
> should test $(enable_shared) while Makefile.in should test $(PICFLAG) when
> deciding whether to create a pic subdirectory and populate it with PICFLAG
> (e.g., -fPIC) files. If $(enable_shared) pulls in a fragment which
> defines PICFLAG, the PIC machinery is engaged, but $(enable_shared) only
> should signify that shared libraries have been requested, not how to build
> the shared libraries.
>
> Before I submit patches, does anyone know of a design problem with
> this proposal? Browsing the sources, I could not find any configuration
> fragment that would be confused by this change.
>
> The changes are of the form below. My question at the moment is
> about which flag is tested, not the details of which form of Unix test is
> used in the Makefile. We can discuss the preferred syntax once the basic
> concept is okay.
The only potential problem area I see is that some systems (alpha?) also
always generate PIC by default, but do require -fPIC to get code that is
suitable for shared libraries. But those kinds of systems can just
define PICFLAG, right?
Yes, the base concepts seem sound to me.
jeff
>
> Thanks, David
>
>
> Index: Makefile.in
> ===================================================================
> RCS file: /cvs/gcc/egcs/libiberty/Makefile.in,v
> retrieving revision 1.42
> diff -c -p -r1.42 Makefile.in
> *** Makefile.in 2000/04/29 14:25:12 1.42
> --- Makefile.in 2000/05/02 22:57:59
> *************** INCDIR=$(srcdir)/$(MULTISRCTOP)../includ
> *** 108,115 ****
>
> COMPILE.c = $(CC) -c @DEFS@ $(LIBCFLAGS) -I. -I$(INCDIR) $(HDEFINES) @ac_
> libiberty_warn_cflags@
> .c.o:
> ! test x"$(enable_shared)" != xyes || \
> ! $(COMPILE.c) $(PICFLAG) $< -o pic/$@
> $(COMPILE.c) $<
>
> info: info-subdir
> --- 108,116 ----
>
> COMPILE.c = $(CC) -c @DEFS@ $(LIBCFLAGS) -I. -I$(INCDIR) $(HDEFINES) @ac_
> libiberty_warn_cflags@
> .c.o:
> ! if [ x$(PICFLAG) != x ]; then \
> ! $(COMPILE.c) $(PICFLAG) $< -o pic/$@ \
> ! else true; fi
> $(COMPILE.c) $<
>
> info: info-subdir
> *************** required-list: Makefile
> *** 185,191 ****
> echo $(REQUIRED_OFILES) > required-list
>
> stamp-picdir:
> ! if [ x"$(enable_shared)" = xyes ] && [ ! -d pic ]; then \
> mkdir pic; \
> else true; fi
> touch stamp-picdir
> --- 186,192 ----
> echo $(REQUIRED_OFILES) > required-list
>
> stamp-picdir:
> ! if [ x$(PICFLAG) != x ] && [ ! -d pic ]; then \
> mkdir pic; \
> else true; fi
> touch stamp-picdir
>
> ===========================================================================
> ====
> David Edelsohn T.J. Watson Research Ce
> nter
> dje@watson.ibm.com P.O. Box 218
> +1 914 945 4364 (TL 862) Yorktown Heights, NY 10
> 598
>