Hi.
Most (if not all) of Osmocom libraries can be built for static linking. With the addition of https://gerrit.osmocom.org/#/c/2748/ we can leverage this to also build static OpenBSC which comes in handy while testing from time to time.
Would be nice to add this option to jenkins as well (for OpenBSC as well as all the libraries).
What do you think?
Hi Max,
I also saw your patch in gerrit, but I was wondering ... why? Where's the use case, except higher build times and larger binaries? Is it worth spending time on this?
Regards, Harald
Well, in my case I wanted to quickly test on a remote host without build environment (internal ref. - gbproxy issue). It turned out that it doesn't work - way too different hosts (libc, compiler etc).
As for general use-case - I'm not sure. Hence, this email to start the discussion.
29.05.2017 18:47, Harald Welte пишет:
I also saw your patch in gerrit, but I was wondering ... why? Where's the use case, except higher build times and larger binaries? Is it worth spending time on this?
On Mon, May 29, 2017 at 07:46:56PM +0200, Max wrote:
Well, in my case I wanted to quickly test on a remote host without build environment (internal ref. - gbproxy issue). It turned out that it doesn't work - way too different hosts (libc, compiler etc).
ah, thanks for the clarification. Now it actually makes more sense.
(sorry for top posting, but I remember otherwise you have issues reading HTML quotation)
We originally created these patches when developing changes touching both libosmocore and osmo-nitb. So that instead of reinstalling a whole bunch of Debs every time we would want to test something, we could just drop a single binary, test it and switch back to whatever is running there normally.
There is a few other use cases when we found this option very handy. Once merged, we would probably use it for deployment as well.
Please excuse typos. Written with a touchscreen keyboard.
-- Regards, Alexander Chemeris CTO/Founder Fairwaves, Inc. https://fairwaves.co
On May 29, 2017 9:15 PM, "Harald Welte" laforge@gnumonks.org wrote:
On Mon, May 29, 2017 at 07:46:56PM +0200, Max wrote:
Well, in my case I wanted to quickly test on a remote host without build
environment
(internal ref. - gbproxy issue). It turned out that it doesn't work -
way too
different hosts (libc, compiler etc).
ah, thanks for the clarification. Now it actually makes more sense.
--
- Harald Welte laforge@gnumonks.org
http://laforge.gnumonks.org/
================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Mon, May 29, 2017 at 07:46:56PM +0200, Max wrote:
Well, in my case I wanted to quickly test on a remote host without build environment (internal ref. - gbproxy issue). It turned out that it doesn't work - way too different hosts (libc, compiler etc).
As for general use-case - I'm not sure. Hence, this email to start the discussion.
Could also make sense for the osmo-gsm-tester. So far we are building all the osmo libraries and actually copy them over to the main unit as well, meaning we need to set an LD_LIBRARY_PATH when launching a binary. But it is a bit of a "gamble", or, say, uncertainty whether the remaining dependencies on the main unit match the build server. If we built one single static binary and send it to the main unit, it would probably be more certain to work as intended at build time?
So far I have a ticket to drop static libraries from the build artifacts. Instead we could drop all libraries (dynamic and static) and only send the readily linked static binary. http://osmocom.org/issues/2303
~N
-
Alexander Chemeris -
Harald Welte -
Max -
Neels Hofmeyr