User talk:Ywwg: Difference between revisions
No edit summary |
|||
| Line 25: | Line 25: | ||
I saw a very old message of yours on the sugar mailing list archive, talking about your experience bundling .so files into penguintv. I want to make some changes to a gtk widget (gtksourceview, so it accepts dynamically generated language definition files, see [[bityi]] for why) and bundle that in my activity. Can you give me an update of what you said back then? Note that since it's a gtk widget, I need both the python bindings and the widget itself, and I need some way to tell the python bindings where to find the widget - this last step is what has me confused at the moment. I'm gonna email you, but I think that the wiki is the best place to have this discussion so it is preserved for others. Cheers, [[User:Homunq|Homunq]] 13:03, 11 February 2008 (EST) |
I saw a very old message of yours on the sugar mailing list archive, talking about your experience bundling .so files into penguintv. I want to make some changes to a gtk widget (gtksourceview, so it accepts dynamically generated language definition files, see [[bityi]] for why) and bundle that in my activity. Can you give me an update of what you said back then? Note that since it's a gtk widget, I need both the python bindings and the widget itself, and I need some way to tell the python bindings where to find the widget - this last step is what has me confused at the moment. I'm gonna email you, but I think that the wiki is the best place to have this discussion so it is preserved for others. Cheers, [[User:Homunq|Homunq]] 13:03, 11 February 2008 (EST) |
||
The trick is compiling with a relative RPATH, like "./lib", so that no matter where the activity is installed, the loader will always look in the right place for the library. |
|||
For instance, if my python widget needs access to libfoo.so, normally during compilation and linking I'd know that libfoo.so would be in a specific place -- /usr/lib, /usr/local/lib, etc. On the OLPC, however, you're not allowed to install .so files, so they must be in the bundle. And the bundle could be anywhere, so the linker doesn't know what the absolute path of the lib will be. |
|||
So, we compile with a relative path like "./lib" and put the file in the bundle like this: |
|||
/foo/bar/my_bundle/whatever.activity |
|||
/foo/bar/my_bundle/lib/libfoo.so |
|||
If the current working directory is my_bundle/, when the loader goes to link up the python widget it looks for libfoo.so in my_bundle/lib, finds it, and links. |
|||
Revision as of 15:44, 14 February 2008
Welcome to the One Laptop per Child wiki. Please make yourself at home; read through the Table of Contents and FAQ, and take a look around. If you need a general wiki-tutorial, Wikieducator has some excellent ones.
Some possible pages of interest:
Check your preferences and be sure you verify your email address and turn on email notification if you'd like it -- you can find out when your talk page, or any page on your watchlist, is modified. You may want to upload a photo or information about yourself to your userpage (examples: 1, 2).
Some open tasks:
- Edit Patrol: recent changes, new pages
- General Cleanup: Category:cleanup
- Expand Articles: Category:stub
- Translation: Localization
Feel free to leave me a note on my talk page if you have further questions or need help finding your way around.
Cheers, Sj
sonata activity
Very cool. Any screen/audioshots of it working? Sj talk 00:19, 11 August 2007 (EDT)
Bundling .so files in an activity
I saw a very old message of yours on the sugar mailing list archive, talking about your experience bundling .so files into penguintv. I want to make some changes to a gtk widget (gtksourceview, so it accepts dynamically generated language definition files, see bityi for why) and bundle that in my activity. Can you give me an update of what you said back then? Note that since it's a gtk widget, I need both the python bindings and the widget itself, and I need some way to tell the python bindings where to find the widget - this last step is what has me confused at the moment. I'm gonna email you, but I think that the wiki is the best place to have this discussion so it is preserved for others. Cheers, Homunq 13:03, 11 February 2008 (EST)
The trick is compiling with a relative RPATH, like "./lib", so that no matter where the activity is installed, the loader will always look in the right place for the library.
For instance, if my python widget needs access to libfoo.so, normally during compilation and linking I'd know that libfoo.so would be in a specific place -- /usr/lib, /usr/local/lib, etc. On the OLPC, however, you're not allowed to install .so files, so they must be in the bundle. And the bundle could be anywhere, so the linker doesn't know what the absolute path of the lib will be.
So, we compile with a relative path like "./lib" and put the file in the bundle like this:
/foo/bar/my_bundle/whatever.activity /foo/bar/my_bundle/lib/libfoo.so
If the current working directory is my_bundle/, when the loader goes to link up the python widget it looks for libfoo.so in my_bundle/lib, finds it, and links.