Hello,
I was going on with the autotools cleanup (in order of listing in cgit) but I'm a bit surprised about the libosmo-sccp structure, which contrarily to libosmocore, libosmo-abis and libosmo-dsp is not using libtool, but it's actually building three static archives, with one source file each.
Now, I don't know if it might be too late to consider changing this but I'm wondering why it has been done this way; when using a shared object it might make sense (although the overhead of using more than one object is probably higher than loading the unused code), but with static archives all the Unix link editors I know only take by default only the objects that are actually needed by what it's being linked; that is using a single libosmo-sccp.a will only bring in the final linking the object files that are actually needed.
I also wonder if it wouldn't make more sense to have everything built in the same project/source tree with libosmocore — in general this seems to be small enough, and the time/space spent for these three files is probably well recovered by the extra ./configure run that it has to run.
Let me know if I can be of help — I'll still send the autotools cleanup for this project today I think.
Hi Diego,
On Wed, Jul 04, 2012 at 02:15:20PM +0200, Diego Elio Pettenò wrote:
I was going on with the autotools cleanup (in order of listing in cgit) but I'm a bit surprised about the libosmo-sccp structure, which contrarily to libosmocore, libosmo-abis and libosmo-dsp is not using libtool, but it's actually building three static archives, with one source file each.
I guess this is mostly for historic reasons. Only Holger will know.
I personally would also think it makes sense to merge it into libosmocore. Holger?
On Wed, Jul 04, 2012 at 02:15:20PM +0200, Diego Elio Pettenò wrote:
Hello,
Hi,
thanks for your cleanups. Let me answer the static archives.
static: I have an application/use where having a DSO causes "issues". I know that for Distros I should offer DSOs too.
multiple files: Habbit, for WebKit copying 3GB in .o files into the .a because one file changed.. lead me to create multipe libs. It is certainly overkill for libosmo-sccp and having a single .a file would be okay.
holger
Hi,
Il 05/07/2012 12:49, Holger Hans Peter Freyther ha scritto:
I have an application/use where having a DSO causes "issues". I know that for Distros I should offer DSOs too.
Do you have more details on which issues it is? I've seen many problems related to DSO before, but most of the time they are relatively easy to fix, so if I can be of help I'd gladly do so.
Habbit, for WebKit copying 3GB in .o files into the .a because one file changed.. lead me to create multipe libs. It is certainly overkill for libosmo-sccp and having a single .a file would be okay.
Sounds good then — do you want me to send patches to set that one up, with libtool or something?
If you use libtool, you can decide not to build the shared object simply by using ./configure --disable-shared which then will only build the static archives, if that's still a concern.
HTH,
On Thu, Jul 05, 2012 at 12:57:57PM +0200, Diego Elio Pettenò wrote:
Do you have more details on which issues it is? I've seen many problems related to DSO before, but most of the time they are relatively easy to fix, so if I can be of help I'd gladly do so.
"issues" is really not technical here. For some cases it is easier to deploy one binary than to make sure the dependencies are present and at the right place (or ld.so.conf has the right path or...)
Habbit, for WebKit copying 3GB in .o files into the .a because one file changed.. lead me to create multipe libs. It is certainly overkill for libosmo-sccp and having a single .a file would be okay.
Sounds good then — do you want me to send patches to set that one up, with libtool or something?
sure, libtool sounds fine.
-
Diego Elio Pettenò -
Harald Welte -
Holger Hans Peter Freyther