[ST-devel] Re: Patches to 1.3c to produce rpm/debs

[Wesley W. T. <we...@te...>]

On Mon, Jan 07, 2002 at 11:19:49AM -0800, Gene Shekhtman wrote:
> "Wesley W. Terpstra" wrote:
> 
> > Problem 1:
> >
> > The libraries built right now are not relocatable. I'm not entirely sure
> > what this does, but from packaging libraries before I know that it is
> > supposed to be done. :-)
> >
> 
> A few points on Problem 1.
> 
> - As far as I know, on many platforms (e.g., Solaris, Irix, and *Linux*)
>   compiler emits position-independent code by default.  So there is no
>   need for -fpic/-fPIC flag.  Often these flags are used "just in case",
>   but it doesn't mean they are always needed.

Ok, I've gone and read up on this now to be more sure of things... You are
correct: on linux '-fpic' is implied. However, '-fPIC' is *not*.

This is because it is slower and larger to do position-independent large
displacement branches. So, gcc does some optimization for you: generally
you aren't writing a shared library. Unfortunately, if you are the code must
be fully relocatable to be shared.

For concrete evidence: if the option were truly redundant, the file size
with and without this option would remain the same. It does not: -fPIC makes
the objects bigger. Hence the option does do something in linux. libtool
chooses to use them. Also, most other well-scrutinised packages (even those
that don't use libtool) also use them. eg: libc, libdb3, etc

libc:

/usr/i486-linuxlibc1/bin/gcc -V 2.7.2.3 -b i486-linuxlibc1 -m486
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -O1 -funroll-loops -I.
-I.. -I../libio -I../libio/stdio -DNLS -I../nls  -DYP -DNO_SHADOW
-D_GNU_SOURCE -DSTDC_HEADERS -DUSG -DDIRENT -DSYSV -DUSE_BSD_REGEX -D_LIBC
-DINTERNAL_LINUX_C_LIB -D_REENTRANT  -Wall -Wstrict-prototypes
-Wmissing-prototypes -funsigned-char -I../internal -nostdinc -I../include
-I/usr/lib/gcc-lib/i486-linuxlibc1/2.7.2.3/include -DNIS -DUSE_OPTIONS_H=1
-c inet_ntoa.c -o ../elfstatic/libc/inet_ntoa.o

** Note: elfstatic does not have the -fPIC or -fpic options. They later 'ar'
these .o files up.

/usr/i486-linuxlibc1/bin/gcc -V 2.7.2.3 -b i486-linuxlibc1 -m486
-malign-loops=2 -malign-jumps=2 -malign-functions=2 -fPIC -O6 -funroll-loops
-fomit-frame-pointer -g1 -I. -I.. -I../libio -I../libio/stdio -DNLS -I../nls
-DYP -DNO_SHADOW  -D_GNU_SOURCE -DSTDC_HEADERS -DUSG -DDIRENT -DSYSV
-DUSE_BSD_REGEX -D_LIBC -DINTERNAL_LINUX_C_LIB -D_REENTRANT  -Wall
-Wstrict-prototypes -Wmissing-prototypes -funsigned-char -I../internal
-nostdinc -I../include -I/usr/lib/gcc-lib/i486-linuxlibc1/2.7.2.3/include
-DNIS -DUSE_OPTIONS_H=1  -c inet_ntoa.c -o ../elfshared/libc/inet_ntoa.o

** Note: elfshared uses -fPIC, they compiled inet_ntoa twice, and they later
use 'ld' on these objects.

> - According to gcc man page, -fPIC is a superset of -fpic, so you don't
>   need both of them (if you need them at all).

I agree, -fPIC is probably sufficient since libc uses it alone. I just put
both in because that's what libtool does and in all things library I defer
to it just in case. :-)

> - It's OK to have relocatable objects in an ar archive (.a).  So there
>   is no need to compile twice.

It is indeed ok, but it's slower and larger. Generally people want the
static library to not have pic code. Since I was repeatedly told that speed
is important, I stuck with that. According to one of the links below the
impact of position independent code is about 5%.

You may be interested to read:
http://www.io.com/help/linux/ELF-HOWTO-1.html
which explains that -fPIC is needed and the pic speed impact.

Also, item 4.2 in:
http://chandra.ph1.uni-koeln.de/linux/debian/debian-policy/ch4.html
which mentions that one should compile libraries twice.

-- Aside:

Interestingly, this item also mentions that for a library you should use
-D_REENTRANT so that it will work with multithreaded applications
(pthreaded I presume)... This probably counts doubly for libst!

-- 
Wesley W. Terpstra <we...@te...>