This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PIC and libiberty
- From: Ian Lance Taylor <ian at airs dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: binutils at sources dot redhat dot com
- Date: 03 Feb 2005 22:43:29 -0500
- Subject: Re: PIC and libiberty
- References: <vt26519mupc.fsf@zenia.home> <m3acqlo6z4.fsf@gossamer.airs.com><vt21xbxmd93.fsf@zenia.home>
Jim Blandy <jimb@redhat.com> writes:
> > Is the problem that there are no PIC object files for libiberty (they
> > would be in the object directory libiberty/pic)? Or is the problem
> > that they do exist, but that the SID build procedure can't find them?
>
> Several things suspiciously fail to conspire to produce PIC files in
> libiberty:
>
> - The host makefile fragment for Linux (if there is one at all?)
> doesn't set PICFLAG.
On x86 Linux PICFLAG is set from config/mh-x86pic, as chosen by
libibert/config.table.
> - The top-level makefile doesn't propagate its value of PICFLAG to
> subconfigures or submakes.
This doesn't matter, because nothing other than libiberty uses
PICFLAG. Everything else uses libtool.
> - libiberty/configure.ac wouldn't do anything with a value for PICFLAG
> that was passed to it.
configure.ac wouldn't, but libiberty/Makefile.in would.
> - Libiberty/Makefile.in doesn't have the @cookie@ in the assignment to
> PICFLAG, so it'll never get a non-empty value.
Yes, it will, from the config fragments selected by
libiberty/config.table.
> What I'm getting at is, I don't think there have been any pic files in
> libiberty for some time.
When I configure with --enable-shared, I see them in libiberty/pic.
Ian