Libraries only provides .a, no .so - Bullet physics engine
- To: firstname.lastname@example.org
- Subject: Libraries only provides .a, no .so - Bullet physics engine
- From: Wen-Yen Chuang <email@example.com>
- Date: Thu, 22 May 2008 05:42:09 +0800
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <20080521135952.GF29549@LKG28F4DC.example.org>
- References: <4833BDD9.email@example.com> <handler.s.C.firstname.lastname@example.org> <20080521095030.GC29549@LKG28F4DC.example.org> <48340A17.email@example.com> <20080521135952.GF29549@LKG28F4DC.example.org>
-----BEGIN PGP SIGNED MESSAGE-----
Gonéri Le Bouder wrote:
> I saw your question about the .a too late. Can you contact upstream
> (and Cc: the list) to know if they planted to release a shared lib one
Upstream author of Bullet suggests using forum instead of e-mail.
I browsed the forum and list answers from upstream below:
(For the list, I am talking about ITP: #476284).
Erwin (upstream author of Bullet) wrote:
> Bullet is not meant as a system-wide library.
> The behaviour changes with different versions,
> and you don't want a new version of a .dll/.so change and
> break existing other applications that use Bullet.
> The manual tells how to use Bullet: simply add the Bullet/src folder
> to your project, compile, link and run your application.
> Please use static linked library, just like the Bullet demos do.
> Each project (Blender, Bullet demos, other) has its own version of
> Bullet/src embedded. I choose this on purpose: different versions of
> Bullet physics will have (slightly) different simulation behaviour.
> And once a game or app is tuned, you don't want to upgrade the physics
> anymore, it would break everything.
> At the moment, all C++ classes are directly exposed to the developer,
> so he/she can use and extend them in any way. Such a rich C++ interface
> doesn't suit a shared / dynamic library very well I think.
> There is plans for an optional C-API, and it would be easier to expose
> the Bullet library with such C-API as shared library.
> But someone will need to go through the trouble of adding
> additional/optional support for such shared library build setting
> (either for C++ or C API).
It is possible to provide .so, and it is proved to be working.
However, maintainers have to handle all the ABI changes and select
suitable so versioning. Upstream of Bullet does not support shared
Do we have to provide .so?
Or just provides .a, like what upstream suggests?
Bullet includes some nice demo programs, it is worthy to be debianized
even if we do not provide shared libraries.
Wen-Yen Chuang (caleb)
My GPG key is signed by Debian Developer Masayuki Hatta.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----