|
Home > Archive > Unix Programming > May 2006 > -fPIC and shared libs
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
-fPIC and shared libs
|
|
|
| Hi,
I was reading a document and I have little doubts about the below
paragraph :
Most architectures have the constraint that shared libraries need to be
compiled as PICcode using the -fPIC switch to GCC.
Even for those architectures that allow it, like x86, it
is not desirable to do so since a shared library should live once in the
memory and get then shared by all applications using it. But non-PIC
code cannot be shared.
Why cant non-PIC code cannot be shared ? Position Independent Code just
helps us in loading the library at any address map and the internals
symbols realign themselves to the correct addresses.
Please correct me if I am wrong.
Thanks,
~
| |
| Paul Pluzhnikov 2006-05-11, 1:20 am |
| grid <prohit99@gmail.com> writes:
> Why cant non-PIC code cannot be shared?
There are too many negations in the above sentence.
Non-PIC code could be shared, but this is very unlikely to happen.
> Position Independent Code
> just helps us in loading the library at any address map and the
> internals symbols realign themselves to the correct addresses.
You appear to have very vague understanding of how PIC code works.
Symbols certainly don't just magically "realign themselves".
If you want to understand how it actually works, here is one
place that provides relevant details:
http://www.iecc.com/linker/linker10.html
> Please correct me if I am wrong.
Since you didn't make any statements, you can't be wrong 
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Roy L Butler 2006-05-11, 7:15 pm |
| Paul Pluzhnikov wrote:
> grid <prohit99@gmail.com> writes:
>
>
> There are too many negations in the above sentence.
> Non-PIC code could be shared, but this is very unlikely to happen.
>
>
> You appear to have very vague understanding of how PIC code works.
> Symbols certainly don't just magically "realign themselves".
>
> If you want to understand how it actually works, here is one
> place that provides relevant details:
> http://www.iecc.com/linker/linker10.html
>
>
> Since you didn't make any statements, you can't be wrong
>
> Cheers,
On sort of a tangent, I remember many years back when I attempted to
replace libc.so on an Irix system only to be greeted by a lock-up.
Since then, I've learned about how for some key shared libraries, MS
Windows handles upgrades by placing them in a "to be installed on next
boot", which does so before much is loaded. It's also why I take is
some Sun patches want single-user mode.
I read the web page listed; is all of what I described due to offsets
changing in new libraries, due to function machine code growth or
shrinkage? If so, or in any case, I wonder how Red Hat and SuSE handle
Linux updates, which appear to install RPMs in place on a live system.
Furthermore, as a test on a testbed FreeBSD system, I've once rebuilt
and installed the GNOME desktop and all of its libraries overwriting
what was there, while running GNOME. How could this have worked? My
guess is the key data and instructions were already loaded in and the
libraries no longer had to be referred to, but if anyone has ideas on
this, I'd really be interested.
Roy
|
|
|
|
|