Re: geography/gdal-lib: devel/netcdf + devel/libexecinfo

[Greg Troxel <gdt%lexort.com@localhost>]

Brook Milligan <brook%nmsu.edu@localhost> writes:

>> On Aug 18, 2023, at 8:17 AM, Greg Troxel <gdt%lexort.com@localhost> wrote:
>> 
>> 
>>> Yes, netcdf builds fine.  I have attached netcdf.pc.  It seems to be like yours; neither makes mention of libexecinfo.
>> 
>> So I don't see why gdal is adding -lexecinfo.  That is the real question.
>
> I’m not sure.
>
> However, the source of the problem is that netcdf/buildlink3.mk lacks
> a reference to libexecinfo/buildlink3.mk.  (It does include four other
> buildlink3.mk files.)  If that is added, gdal-lib builds just fine.
> (I have not tried any other packages that depend on netcdf.)

Ah, I see.

I have long been not 100% clear on this, in that just because libnetcdf
links with execinfo does not mean that execinfo should appear in the
build of something that uses netcdf.  But we have longstanding issues
where libtool reaches in and includes private libs, and then there's
static linking.

> Unless I hear otherwise, I’ll commit that change soonish.

I do not object to that.   I just didn't want to be doing something that
was specifically to make it build on mac when it didn't seem like the
right thing in general.

This can explain why there is no -L; it should be to the bl3 libdir with
-L, not the installed libdir.

> This raises a broader question: when must buildlink3.mk include other buildlink3.mk files?  Are those conditions well documented anywhere?

A very hard question to answer exactly, and in theory the pkgsrc guide
should say.

Basically

  if package A bl3's on B, and might do -llibb, then any libs that B
  depends on that have to be directly referenced for that link need to
  be included via bl3, so they are visible.

that just punts to "have to be directly referenced" without answering
the hard question.   But library linking is messy and variable.


We still don't know how -lexecinfo gets into either netcdf's or
gdal-lib's build.