glib.h not found

[anbj]

Tested on git head and 5.8.1.

I'm getting an error which is new to me:

[ 73%] Building C object src/mbaux/CMakeFiles/mbaux.dir/mb_readwritegrd.c.o
[ 73%] Built target mb_read_init_test
[ 77%] Built target mbview
In file included from /usr/local/include/gmt/gmt_dev.h:157,
                 from /home/anbj/MB-System/src/mbaux/mb_readwritegrd.c:39:
/usr/local/include/gmt/gmt_glib.h:36:10: fatal error: glib.h: No such file or directory
   36 | #include <glib.h>
      |          ^~~~~~~~
compilation terminated.

It seems to come from a gmt header file. I've installed the dependencies.

This 'error' may not belong to MB-System, but creating this report in hope for some tips. @joa-quim, do you know of any changes lately that may lead to this?

[joa-quim]

It seems that somehow this is related to what triggered GenericMappingTools/gmt#8577
But gmt_glib.h:36 has

#ifdef HAVE_GLIB_GTHREAD
#include <glib.h>

So, if HAVE_GLIB_GTHREAD is set that means the location of glib.h should be know too. Don't understand the failure.

[dwcaress]

Joaquim, I don’t have time to work on it now, but I suspect the problem is that GLIB has been found but that the CMakeList.txt file in mbsystem/src/mbaux does not add GLIB to the target include directories and link libraries lists. Cheers, Dave

…

On Oct 22, 2024, at 3:07 PM, Joaquim ***@***.***> wrote: It seems that somehow this is related to what triggered GenericMappingTools/gmt#8577 <GenericMappingTools/gmt#8577> But gmt_glib.h:36 has #ifdef HAVE_GLIB_GTHREAD #include <glib.h> So, if HAVE_GLIB_GTHREAD is set that means the location of glib.h should be know too. Don't understand the failure. — Reply to this email directly, view it on GitHub <#1484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXCC5QQAJPLWOOYIS4LZ43EDDAVCNFSM6AAAAABQNIQQ3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZQGQYDGOBXGQ>. You are receiving this because you are subscribed to this thread.

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 ***@***.*** https://www.mbari.org/person/dave-caress/ https://www.mbari.org/team/seafloor-mapping/ Phone: 831-775-1775

[anbj]

It's a recent thing at least. I'm pretty sure I successfully compiled MB-system just a few weeks/months ago (with bleeding edge GMT). I know for sure it worked in May, so the reason you refer to @joa-quim seems probable.

[anbj]

I checked out an arbitrary GMT commit some months ago and started git bisect.
I ended up with this commit:

20cbbffe6396749b563d0c335e3f8116d14ffa47 is the first bad commit
commit 20cbbffe6396749b563d0c335e3f8116d14ffa47
Author: Joaquim <[email protected]>
Date:   Wed Jun 19 13:46:54 2024 +0100

    Use all cores by default in grdfilter (#8523)
    
    * Let x option synopsis be printed in grdfilter independently of having OMP or not.
    
    * Let all 3 modules built with Glib use max number of cores by default like the OMP case.
    
    * Do not use multi-threads with -Ff (custom filter). It's broken.
    
    * Use API->n_cores instead of gmtlib_get_num_processors() to see if it pleases Mac
    
    * Do not use all cores by default in potential modules. Some tests are failing.
    
    Integrate the ideas of #8319
    
    * Remove mention to -x option (not in current surface module).
    
    Variable filter width (grdfilter) does not support -x

 doc/rst/source/explain_core.rst_ |  4 +++-
 src/gmt_dev.h                    |  1 +
 src/gmt_glib.h                   |  1 +
 src/gmt_init.c                   | 20 ++++++++++++--------
 src/grdfilter.c                  | 18 ++++++++++++++++--
 src/potential/gmtgravmag3d.c     |  2 +-
 src/potential/grdgravmag3d.c     |  2 +-
 src/surface.c                    |  4 ++--
 8 files changed, 37 insertions(+), 15 deletions(-)

@joa-quim, do you know how to fix this?

[joa-quim]

But that I understand this, there is nothing to fix in the GMT side!

[anbj]

Oh, sorry!

[anbj]

Just for the record: compiling MB-System works with GMT 6.5.0, but after the commit in the GMT repo on Jun 19., the fatal error: glib.h: No such file or directory error appears.

[dwcaress]

Today I tried, but failed, to replicate the glib.h not found build error using the current beta distribution of MB-System (5.8.2beta18) and the current master branch of the GMT repository (which shows a version 6.6.0). I removed the prior GMT installation (6.5.0), installed GMT 6.6.0 from source, and then built and installed MB-System. This worked successfully on MacOs Ventura 13.40 and on Ubuntu 24.04.1 LTS. I double checked that the GMT 6.5.0 headers and libraries were fully removed and that MB-System was building using the GMT 6.6.0 headers and libraries.

[anbj]

That's very strange. I'll test again when I have the chance.

[dwcaress]

Thinking more about it, it’s likely that the HAVE_GLIB_GTHREAD variable is not getting set when running the MB-System CMake in my environment but is getting set when you run it. Since the MB-System CMake structure does not look for glib explicitly and does not care about glib threads (MB-System uses pthreads), it’s unclear to me how HAVE_GLIB_GTHREAD could possibly be set when gmt_dev.h is included during the compiler preprocessing, which happens in gmt/mbcontour.c gmt/mbgrd2obj.c gmt/mbgrdtiff.c gmt/mbswath.c mbaux/mb_readwritegrd.c. (where the error was triggered in your original report) It’s also true that glib.h is present in my test environments in MacOs and Ubuntu, but I still don’t think the code is including it. A workaround might be to put #undef HAVE_GLIB_GTHREAD immediately before #include gmt_dev.h in the five places where this include exists. Cheers, Dave

…

On Jan 5, 2025, at 11:35 AM, anbj ***@***.***> wrote: That's very strange. I'll test again when I have the chance. — Reply to this email directly, view it on GitHub <#1484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXBF3252263ZVHMUGZD2JGCOXAVCNFSM6AAAAABQNIQQ3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRG4ZDSMBUGA>. You are receiving this because you commented.

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 ***@***.*** https://www.mbari.org/person/dave-caress/ https://www.mbari.org/team/seafloor-mapping/ Phone: 831-775-1775

[anbj]

Thanks @dwcaress. What would a permanent fix be?

[dwcaress]

Since I cannot replicate the problem, I don’t know what the problem actually is, and therefore cannot define an actual fix. Dave

…

On Jan 6, 2025, at 5:24 AM, anbj ***@***.***> wrote: Thanks @dwcaress <https://github.com/dwcaress>. What would a permanent fix be? — Reply to this email directly, view it on GitHub <#1484 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTSXXEOMO6AP3XDYKF3I7D2JJ7Z5AVCNFSM6AAAAABQNIQQ3SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZTGEYDKNBTGU>. You are receiving this because you were mentioned.

---------------------------------------------------- David W. Caress Principal Engineer Seafloor Mapping Lab Monterey Bay Aquarium Research Institute 7700 Sandholdt Road Moss Landing, CA 95039 ***@***.*** https://www.mbari.org/person/dave-caress/ https://www.mbari.org/team/seafloor-mapping/ Phone: 831-775-1775

[anbj]

I see. I'll leave the issue open a while longer. Thanks Dave.