[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" <boris@gtemail.net> 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.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.