Re: make puzzle

[Michael Davidsaver via Core-talk <core-talk at aps.anl.gov>]

On 11/6/20 4:00 PM, Johnson, Andrew N. wrote:
> ...
> For the workstation arch's we have already linked all those target-specific libraries into libCom.so when we created that (LDLIBS is appended to SHRLIB_LDLIBS unconditionally, which is used instead of PROD_LDLIBS for lib.so linking), so there is no need to link against them again. If you aren’t linking your executable with libCom you'd probably need a different set of system libraries anyway.

In the last sentence, when you write "probably".  Do you see this as truly optional?
If so, then you and I may not be disagreeing on this point after all.

In thinking about this, the apparent contradiction I see is that SHARED_LIBRARIES
seems to be used both as a proxy for whether the dependency libCom.so was built, and
whether a local library libwhatever.so will be built.  To me mind these are independent
choices.

If the first part is my misunderstanding, then I no longer see a contradiction,
and we agree that SHARED_LIBRARIES is strictly used to control local library builds.

If this is the case, then do you agree that the original "puzzle":

> LDLIBS_STATIC_YES = LDLIBS
> LDLIBS_SHARED_NO = LDLIBS
> PROD_LDLIBS += $($(firstword $(LDLIBS_STATIC_$(STATIC_BUILD)) \
>               $(LDLIBS_SHARED_$(SHARED_LIBRARIES))))

Could be simplified to:

> PROD_LDLIBS += $(LDLIBS)

With the only "ill" effect being over-linked executables?

over-linking being a "problem" we already have as a side effect of combining
both direct and indirect dependencies in PROD_LIBS to facilitate static linking.