public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* -fpic option
@ 2006-06-01  8:32 satyaakam goswami
  2006-06-01 11:55 ` Tim Prince
  2006-06-01 15:51 ` Brian Dessent
  0 siblings, 2 replies; 3+ messages in thread
From: satyaakam goswami @ 2006-06-01  8:32 UTC (permalink / raw)
  To: gcc-help

Hello ,
          I have a question  ,  When i create two libs with one with
-fpic option and other without it and then include both to create a
binary archive will the both libs work together?

Satya

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: -fpic option
  2006-06-01  8:32 -fpic option satyaakam goswami
@ 2006-06-01 11:55 ` Tim Prince
  2006-06-01 15:51 ` Brian Dessent
  1 sibling, 0 replies; 3+ messages in thread
From: Tim Prince @ 2006-06-01 11:55 UTC (permalink / raw)
  To: satyaakam goswami; +Cc: gcc-help

satyaakam goswami wrote:
> Hello ,
>          I have a question  ,  When i create two libs with one with
> -fpic option and other without it and then include both to create a
> binary archive will the both libs work together?
> 
> Satya
> 
> 
You would expect -fpic to be required for dynamic libraries.  On some of 
the more common operating systems, they should work together if you 
don't violate that requirement.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: -fpic option
  2006-06-01  8:32 -fpic option satyaakam goswami
  2006-06-01 11:55 ` Tim Prince
@ 2006-06-01 15:51 ` Brian Dessent
  1 sibling, 0 replies; 3+ messages in thread
From: Brian Dessent @ 2006-06-01 15:51 UTC (permalink / raw)
  To: gcc-help

satyaakam goswami wrote:

>           I have a question  ,  When i create two libs with one with
> -fpic option and other without it and then include both to create a
> binary archive will the both libs work together?

Note that this is extremely platform specific, and you did not mention
what platform you are using.  You need to be much more specific.

On linux x86 and I believe Solaris on some arches, you can in fact
create shared libraries containing non-PIC code, and they will function,
but very poorly.  Instead of sharing one copy of the .so across each
process that uses it, every process will have to have its own copy in
memory because each copy will have to be modified for that process using
text relocs.  So you waste memory tremendously by doing this, depending
on how many processes use the library.  You might as well just link
statically if you want the speed increase that non-pic code gives you.

On just about every other platform (including x86_64 linux) either PIC
is on by default or trying to add non-PIC objects to a .so will fail
spectacularly.

If you're talking about static linking then PIC-ness shouldn't matter at
all.

Also note that the compiler has nothing to do with this, it's more a
function of the linker, so you should probably follow up on the binutils
mailing list.

Brian

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-06-01 15:51 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-01  8:32 -fpic option satyaakam goswami
2006-06-01 11:55 ` Tim Prince
2006-06-01 15:51 ` Brian Dessent

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).