gumstix

Hi Greg,

> i was hoping to disable FORCE_SHAREABLE_TEXT_SEGMENTS in uclibc in order to
> cross-compile some python modules.
>
> does the gumstix linux absolutely require position independent code (PIC)?
> i'm not looking to use assembly code (obviously).

I believe that the only a couple of portions of the kernel that have
to use position independent code (in the early boot) and that's coded
in assembly.

User mode code (which is what uses uClibc) shouldn't care. Loadable
modules and shared libraries use a linking stage to resolve symbols at
load time.

I think that the reason for enabling the option and using position
independent code is to reduce overall memory requirements. If program
A wants to load libfoo at address X, and program B wants to load
libfoo at address Y, then they can share the code pages if it's
compiled with position independent code.

I'm curious why the python modules would care?

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

python requires it.  any modules that are not PIC are not loadable by  
dlopen and will result in the following:

Can't modify ./_mymodule.so's text section. Use GCC option -fPIC for  
shared objects, please.

i don't know if this can be turned off, but for now i just need to  
make sure all python modules are PIC friendly.

would setting --disable-shared in python's make file remove the  
python requirement for PIC modules?



On Jul 26, 2006, at 7:19 AM, Dave Hylands wrote:

> Hi Greg,
>
>> i was hoping to disable FORCE_SHAREABLE_TEXT_SEGMENTS in uclibc in  
>> order to
>> cross-compile some python modules.
>>
>> does the gumstix linux absolutely require position independent  
>> code (PIC)?
>> i'm not looking to use assembly code (obviously).
>
> I believe that the only a couple of portions of the kernel that have
> to use position independent code (in the early boot) and that's coded
> in assembly.
>
> User mode code (which is what uses uClibc) shouldn't care. Loadable
> modules and shared libraries use a linking stage to resolve symbols at
> load time.
>
> I think that the reason for enabling the option and using position
> independent code is to reduce overall memory requirements. If program
> A wants to load libfoo at address X, and program B wants to load
> libfoo at address Y, then they can share the code pages if it's
> compiled with position independent code.
>
> I'm curious why the python modules would care?
>
> -- 
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys -- and earn  
> cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@...
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

[cut]

>I'm curious why the python modules would care?
>
>  
>
I think that there's an uclibc option to forcing text pages sharing. 
That would require all libraries to be pic. If I'm not mistaken, Perhaps 
that particular library was not pic and python seems to report the error 
returned by uclibc's dlopen().  I guessed looking at the flags he used 
that the code is compiled pic, but the shared library is not linked as 
PIC (though the code therein is probably PIC, dlopen() probably checks 
some ELF header to see if the entire thing was built that way or not).

I think it would be a good idea to try passing the -fPIC to the gcc link 
command and see if that helps.

Alexandre

If anybody is interested, I ran into the same error on a different
application (olsrd, if anybody cares).  It is an application that
supports dynamically loaded "plugins".  I tried dynamically loading
one of the plugins and got the same "Can't load ... compiled with
-fPIC" error.  I spent an hour or so being very confused by this
because the the compile obviously used -fPIC for allof the plugins.
It turned out that the the link stage for the plugin incuded a .o file
from the main portion of the tree that was not compiled wiht -fPIC.
When I changed things so that _everything_ was compiled with -fPIC, it
worked.

--wpd