Add article which explains how to bundle libraries not on the image

Bug #1451342 reported by Daniel Holbach
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Developer Portal
New
High
David Callé

Bug Description

Add article which explains how to bundle libraries not on the image

Revision history for this message
Daniel Holbach (dholbach) wrote :

David: XiaoGuo just let me know that this is very important for the competition which ends May 15th. Is this something we can do? (I'll ask on the mailing list for somebody to provide some pointers.)

Revision history for this message
XiaoGuo, Liu (liu-xiao-guo) wrote :

A use case of the bug is at https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1451325. A developer is developing a PDF reader on our phone platform. A lib is missing in the phone image. I am currently making a request to add it to the phone image since PDF reader is a essential on our platform. In the meanwhile, we probably need to tell developers on how to package extra libs into the click package if the libs will finally not be there in the phone image. Recompiling the source codes for the libs seems not a realistic case for most of the developers.

David Callé (davidc3)
Changed in developer-ubuntu-com:
assignee: nobody → David Callé (davidc3)
importance: Undecided → High
Revision history for this message
Daniel Holbach (dholbach) wrote :

Sam Segers says he used https://github.com/labsin/CMakeModules/blob/master/CLICKDeployLibs.cmake - it might need changes though.

Revision history for this message
Florian W. (florian-will) wrote :

I use this in my CMakeLists.txt file in the "backend" directory (not sure if that app template is still in use today):
http://paste.ubuntu.com/10984301/

Of course, the lib*-dev packages need to be installed in all the click build chroots first.

Probably quite sloppy compared to the other solution posted above. It searches the system for a correctly named library, then follows symlinks to get the real .so file, then cuts off everything behind the major lib version (i.e. libfoo.so.9.5.2 => libfoo.so.9). That file is then marked for installation into ${QT_IMPORTS_DIR}. A proper symlink etc. would be nicer of course, but I couldn't get ldconfig to do the right thing, so I just renamed the .so file to drop anything but the major version number.

I also had a snippet to link the .a libs statically into my .so QML plugin, which works on amd64 and possibly other arches, but it failed on at least one arch. I think it was i386. IIRC, the compilation process for .a static libs needs a special flag for position independent code to make linking a static lib into a shared lib possible.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.