Attention is currently required from: pespin, fixeria.
1 comment:
File src/libosmo-pfcp/Makefile.am:
Patch Set #1, Line 68: gen__pfcp_ies_auto_LDFLAGS
Regarding order: lower level libs (eg libosmcoore) should be *after* the libs depending on it. […]
this is the same fix: LDADD I presume appends libs to the AM_LDFLAGS from above. Since AM_LDFLAGS include LIBOSMOCORE_LIBS, then the local lib is appended by LDADD after libosmocore, which then fails. By using LDFLAGS, not LDADD, the order is being fixed, because no other libs are listed before libosmo-gtlv.a.
Now from a different angle, linking is only done for built programs. Since this Makefile.am builds only a library (not linked) and the gen__pfcp... program (linked), that means the global AM_LDFLAGS only applies to this gen__pfcp program anyway, so it makes no sense to set AM_LDFLAGS and then also have a separate LDFLAGS for the gen__pfcp program. I can just use either the global AM_LDFLAGS or a gen_pfcp_..._LDFLAGS. Hope this is correct now... certainly works on my box.
re: "COVERAGE_LDFLAGS should be in gen__pfcp_ies_auto_LDFLAGS . Why are they mixed up?"
But so far I don't understand why you would say that COVERAGE has to be in LDFLAGS, when both LDFLAGS and LDADD just end up adding cmdline args to the linker. should COVERAGE come first??
I presume LDFLAGS and LDADD are the same thing, one replaces the earlier LDFLAGS and the other doesn't replace but just append? I have no idea about COVERAGE_LDFLAGS, if that needs fixing let's do it in a separate patch. I don't even know what COVERAGE is supposed to do... just took it from another build tree.
To view, visit change 31741. To unsubscribe, or for help writing mail filters, visit settings.