Соединение общей библиотеки против статической библиотеки: статическая библиотека должна быть скомпилирована по-другому, чем если бы приложение связывало ее?
В установке Java-Webstart Вы запускаете файл JNLP, который затем инициировал загрузку файлов Банки, должен был запустить приложение. Каждый раз webstart проверяет, существуют ли более новые версии Банок и загрузили бы их заменяющий локально кэшируемые. С инструментом, названным jardiff, Вы создадите только diffs к более новым банкам и распределите их через сервер (например, только получите обновление).
Профессионалы:
- всегда актуальный
Недостатки:
- Вам нужен сервер приложений (кот, JBoss) для распределения файлов
- , Вам нужно интернет-соединение для получения приложения
2 ответа
You do not have to use PIC code in shared objects (as you have discovered you can use the -mimpure-text option to allow that).
That said, non-PIC code in shared objects are more heavyweight. With PIC code, the text pages in memory are just direct memory mappings of the text pages on disk. This means that if multiple processes are using the shared object, they can share the memory page.
But if you do not have PIC code, when the runtime linker loads the shared object, it will have to apply fixups to the text pages. This means that every processes that uses the shared object will have it's own unique version of any text page that has a fixup on it (even if the shared object is loaded at the same address as copy-on-write only notices that the page was modified and not that it was modified in the same way).
To me, the important issue is whether you will simultaneously have multiple processes running that each load the shared object. If you do, it is definitely worth making sure all the code within the SO is PIC.
But if that is not the case and only a single process has the shared object loaded, it's not nearly as critical.
В качестве альтернативного подхода отправьте две библиотеки: вашу совместно используемую и статическую, с которой вы связываете вместе. Они должны правильно связываться с финальным исполняемым файлом.