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

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

> 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.

Have you tried to run the netcdf command-line tools that link against
netcdf, and thus presumably indirectly with execinfo?  Just because it
builds doesn't mean it is ok.  I am not trying to point fingers, but to
assume nothing and validate as many steps as possible, because surely
one of them is off.

> I have also attached the lib/libnetcdf.settings file, which does make
> mention of -lexecinfo in LDFLAGS.

ok, but that is presumably LDFLAGS to be used for building netcdf, not
for things that use netcdf to have to add.

> The gdal build fails with the error 
>
> 	ld: library not found for -lexecinfo

There are two mysteries here:

  Why is a gdal build line in pkgsrc not including -L for the pkgsrc
  libdir when gdal uses a vast number of libs also from pgksrc?

  Where did it get the idea it should use execinfo?  I think you said
  that if you drop execinfo from netcdf's Makefile and bl3, things
  build.  If true, try dropping from bl3 only.  I am having trouble
  keeping track.   And, when gdal builds if netcdf doesn't use execinfo,
  is the build log free of execinfo?

> I have attached the last line from .work.log, which I believe to be
> the failing command line.  Note the -lnetcdf, -lexecinfo (and other
> pkgsrc libraries), but no -L for the installed pkgsrc libraries.

I would look at the details of the gdal build to figure out why
-L/path/to/pkgsrc/lib is missing from LDFLAGS, and if it's in general,
or just that one.

> I hope this gives some clues for identifying the issue.
>
> Thanks for your help.

You're welcome but I'm mostly just asking difficult questions.

I would suggest finding other things that depend on netcdf and trying to
build them, just because it could be illuminating.



Separately, note that gdal is a major version behind because upstream
removed autoconf support, and therefore updating is more work, gdal
breaking is really bad, and gdal being slightly behind is not yet
painful.

I have no idea what will change with the autoconf->cmake transition, but
I expect some fixage and some breakage, just because gdal is so
enormous.  But maybe fairly little; I have tested cmake builds on NetBSD
9 amd64 from gdal git.