[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Don't use -fpic if library is too specialized?

From: Paul Pluzhnikov
Subject: Re: Don't use -fpic if library is too specialized?
Date: Wed, 27 Sep 2006 20:35:36 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)

"Boris" <> writes:

> I'm reading as much about PIC as I can find in order to understand if I 
> should compile a library here with or without -fpic. After all I tend to 
> believe that in my case it's better not to use -fpic as 1) for this library 
> performance is critical and as 2) the library is too specialized that it 
> will be used by all kind of different applications.

Are you building a shared library, or an archive.

If shared, note that on some platforms (e.g. Linux/x86_64) you simply
can't build a DSO from non-PIC code (i.e. you'll have no choice).

On other platforms, such as Solaris/SPARC, building DSO from non-PIC
is possible but requires using a different specs file.

If archive, this decision will prevent anyone from building a DSO
containing your library (again at least on Linux/x86_64).

> If I assume that at any 
> time there is probably only one program running which makes use of this 
> library PIC doesn't make much sense

If your code is statically linked into the main executable, you
don't gain anything [1] from PIC even if there are multiple copies of
the program running, or multiple programs that have your library
linked in.

[1] Except for -pie executables.

In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]