Hi Pablo,
there is one more thing that would prevent libosmocore from being packaged by distributions right now: We include our own version of talloc. Debian, Fedora and Ubuntu e.g. by now have a shared libtalloc that we should probably use instead of our own copy.
So what I'd like to see is: * split talloc.c from libosmocore and make a libosmotalloc instead * some autotools magic in the applications (openbsc, osmoocom-bb, osmo-tetra, etc.) that would try to # detect whether there is a system-wide libtalloc, if yes use it # if no, use libosmotalloc
The only big question is how to deal with header files, as we do #include <osmocom/core/talloc.h> and in case of the system-wide libtalloc it should instead be #include <talloc.h>
I don't really have a good idea how to handle this. Any ideas?
Regards, Harald
The only big question is how to deal with header files, as we do #include <osmocom/core/talloc.h> and in case of the system-wide libtalloc it should instead be #include <talloc.h>
I don't really have a good idea how to handle this. Any ideas?
We could just have our local talloc have a .pc that includes a -I${PREFIX_STUFF}/osmocom/core/ in the cflags. So that the app always does a #include <talloc.h> Then with autotools we can just check if either talloc.pc or osmotalloc.pc is present (in this order) and add the appropriate CFLAGS to the build.
Alternatively, if during libosmocore compile, we detect global talloc is present, we don't build talloc.c and we have talloc.h be a simple #include <talloc.h> compatibility ?
Cheers,
Sylvain
Hi Sylvain,
On Fri, May 06, 2011 at 02:16:54PM +0200, Sylvain Munaut wrote:
The only big question is how to deal with header files, as we do #include <osmocom/core/talloc.h> and in case of the system-wide libtalloc it should instead be #include <talloc.h>
I don't really have a good idea how to handle this. Any ideas?
We could just have our local talloc have a .pc that includes a -I${PREFIX_STUFF}/osmocom/core/ in the cflags. So that the app always does a #include <talloc.h> Then with autotools we can just check if either talloc.pc or osmotalloc.pc is present (in this order) and add the appropriate CFLAGS to the build.
ok, good idea, makes sense.
Alternatively, if during libosmocore compile, we detect global talloc is present, we don't build talloc.c and we have talloc.h be a simple #include <talloc.h> compatibility ?
I think it shouldn't be a compile-time decision of libosmocore, but a compile-time decision of the application. Especially in the future case of a distribution-supplied libosmocore that may happen at different times.
Regards, Harald
On 05/06/2011 01:44 PM, Harald Welte wrote:
Hi Pablo,
The only big question is how to deal with header files, as we do #include <osmocom/core/talloc.h> and in case of the system-wide libtalloc it should instead be #include <talloc.h>
a) Use #include_next in osmocom/core/talloc.h if one should use libosmotalloc? b) Take the fragile approach and hope the ABI is not changing in talloc c) prefix _talloc with osmo_talloc.. which then is either an (linker) alias to _talloc of libtalloc our own internal lib? Probably fragile as well.. no idea how well aliases across DSOs work. d) Find out if talloc.h is prefixed in Debian and use that way for includes.
-
Harald Welte -
Holger Hans Peter Freyther -
Sylvain Munaut