Attention is currently required from: Hoernchen, fixeria, laforge, osmith, pespin.
1 comment:
Patchset:
If we are linking dynamically against the stuff in CommonLibs/ and GSM/ then I'd say it's unintended.
If that's the case, please submit a patch to always statically link those files into osmo-trx-*.
I didn’t mean dynamic linking specifically for the CommonLibs/ and GSM/ parts. In the native build those are already linked statically into the `osmo-trx-*` binaries, so no additional patch is needed on that front.
My point was more general: for the Emscripten target, dynamic linking isn’t really a workable option, and we need all required code available at final link time.
I see no need for the .pc files since those object files are not expected to be used by other programs, they are internal to osmo-trx.
Regarding the .pc files: while I understand these objects are “internal” from the upstream perspective, in our build we need to reuse those internal libraries when linking `osmo-bts-trx + osmo-trx` into a single final static output (which is then used to produce the resulting wasm + js). Since `osmo-bts` and `osmo-trx` are built separately (no shared Makefile.am), having pkg-config metadata is the simplest/cleanest way to propagate the correct CFLAGS/LIBS for those internal libs across build boundaries.
So the .pc.in files aren’t meant to turn them into a public API — just to make the cross-project static link step reliable for the Emscripten pipeline.
To view, visit change 42243. To unsubscribe, or for help writing mail filters, visit settings.