From: G E. <gel...@gm...> - 2006-07-26 07:24:08
|
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). greg |
From: Dave H. <dhy...@gm...> - 2006-07-26 16:05:24
|
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/ |
From: G E. <gel...@gm...> - 2006-07-26 22:07:20
|
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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Alexandre P. N. <al...@om...> - 2006-07-28 02:56:46
|
[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 |
From: Patrick D. <wp...@gm...> - 2006-08-10 21:11:50
|
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 |