Hi,
I just looked into a build breakage when --disable-static is passed. The first failure is because of:
libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ -no-undefined \ -export-symbols-regex '^osmo_'
The testcases use xua_* sua_ symbols but they are not exported. Shall we export them or shall we forbid --disable-static on libosmo-sccp?
The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too?
holger
Hi Holger,
On Sat, Jun 03, 2017 at 12:17:08AM +0800, Holger Freyther wrote:
The first failure is because of:
libosmo_sigtran_la_LDFLAGS = -version-info $(LIBVERSION) \ -no-undefined \ -export-symbols-regex '^osmo_'
The testcases use xua_* sua_ symbols but they are not exported. Shall we export them or shall we forbid --disable-static on libosmo-sccp?
I actually really liked the idea as an elegant way to have test cases access more "private" / "low-end" functions inside the implementation, while ensuring only proper APIs are exposed to actual applications (which use dynamic libs). I would actually like to use that in all the other libraries / code we have.
So yes, the idea can still be bad, but what other option do we have in terms of having more symbols available to test caeses than those used in production? Manually linking the individual .o files is ugly, as the list keeps growing for each and every unit test as the library code evolves. What about having a separate static library only used for the unit tests, and building that even while --disable-static is used? In that case one could even play games like #define STATIC static in production builds, and define it to nothing in the build for unit tests, if needed.
The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too?
I'm not sure why it should be different from all the other libosmo* libraries in that regard?
On 3. Jun 2017, at 16:40, Harald Welte laforge@gnumonks.org wrote:
Hi Holger,
Hi,
I actually really liked the idea as an elegant way to have test cases access more "private" / "low-end" functions inside the implementation, while ensuring only proper APIs are exposed to actual applications (which use dynamic libs). I would actually like to use that in all the other libraries / code we have.
As time permits I will see if we can get the libtool m4 not generate the --disable-static option or at least error on it.
#define STATIC static in production builds, and define it to nothing in the build for unit tests, if needed.
yes, something like this is done in Qt when building for testing but I think the setup is complicated for us.
The second part is that I had preferred the sccp library to be static only to avoid having to do proper ABI checking/versioning. If we fix the above, maybe we have to fix this part too?
I'm not sure why it should be different from all the other libosmo* libraries in that regard?
Historically as being one of the first libraries? I had no goal of a clean namespace, API, etc.
holger
-
Harald Welte -
Holger Freyther