Re: Bug in the doc?

[Ralf Wildenhues]

Hi Jan,

* Jan Engelhardt wrote on Wed, Sep 28, 2005 at 01:56:17PM CEST:
> 
> the info pages for libtool says
> 
> "   Shared libraries, however, may only be built from
> "position-independent code" (PIC).  So, special flags must be passed to
> the compiler to tell it to generate PIC rather than the standard
> position-dependent code." [libtool.info.gz]

And in general, this is true.  There are exceptions.

> This looks wrong to me. A final program, or a final shared library, does 
> not care if its object files were built with or without -fpic/-fPIC. At 
> least this is the case on GNU/Linux and afaics {Free,Open}BSD. I maybe seen 
> it on the MacOS-X/Darwin too when I last tried building some on 
> Sourceforge CF. On Win32, -fPIC is always in effect.

$ uname -ms
Linux x86_64
$ echo 'int f() { return 42; }
int g() { return f(); }' > a.c
$ gcc -c a.c
$ gcc -shared -o liba.so a.o
usr/bin/ld: a.o: relocation R_X86_64_PC32 against `f' can not be used when 
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
$ gcc -fPIC -c a.c
$ gcc -shared -o liba.so a.o

Note that while this "works" without -fPIC on x86 (or x86_64 in 32bit
mode, FWIW), it has a profound effect on the generated shared library
(search for "text relocations"; this and its advantages and
disadvantages have been explained several times on this list even).

In general, this depends on both the machine and the operating system
involved.  And no, on Win32 you can't ignore the fact whether or not
you're creating a DLL, at least in the general case (search for data
imports/exports, for example).

There are systems, where it makes no difference while compiling, but
only when linking, but you did not mention AIX.  ;-)

Cheers,
Ralf