FindPostgreSQL.cmake finds different library than pg_config reports.

[offroad-bis]

macOS 10.15.7
MapServer 7.6.2
cmake version 3.19.5

A bug in FindPostgreSQL.cmake? if PG_CONFIG is found, then variables are set in cmake to the include and lib dirs specified by pg_config. If not found, it issues a warning that says it will try some defaults.

if (PG_CONFIG)
   exec_program( ${PG_CONFIG} ARGS "--includedir" OUTPUT_VARIABLE PG_INC_PATH )
   exec_program( ${PG_CONFIG} ARGS "--libdir" OUTPUT_VARIABLE PG_LIB_PATH )
else()
   message(WARNING "pg_config not found, will try some defaults")
endif()

But what it does, is try the defaults anyway, which may not be what pg_config reports. On my machine, pg_config outputs the following.

INCLUDEDIR = /usr/local/include
LIBDIR = /usr/local/lib

But cmake finds this instead, which I assume comes from the default search that cmake uses prior to using HINTS and PATHS.

* POSTGIS: /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/libpq.tbd

Was the intended action to use the library and include directories specified by the pg_config executable? If so, should the if block for PG_CONFIG be changed so that, when pg_config is found, it searches only the libraries and include paths output by pg_config. And if pg_config is not found, then search the default paths. Without the NO_DEFAULT_PATH directive, the find_path will search the default paths before ever searching the PATHS specified by pg_config.

if (PG_CONFIG)
   exec_program( ${PG_CONFIG} ARGS "--includedir" OUTPUT_VARIABLE PG_INC_PATH )
   exec_program( ${PG_CONFIG} ARGS "--libdir" OUTPUT_VARIABLE PG_LIB_PATH )
   find_path(POSTGRESQL_INCLUDE_DIR libpq-fe.h
      PATHS
      ${PG_INC_PATH}
      NO_DEFAULT_PATH  # Stops cmake from looking in default places.
   )
   find_library(POSTGRESQL_LIBRARY NAMES pq libpq
      PATHS
      ${PG_LIB_PATH}
      NO_DEFAULT_PATH # Stops cmake from looking in default places.
   )
else()
   message(WARNING "pg_config not found, will try some defaults")
   
   # The rest was moved into the else block so it does search default places if pg_config was not found
   find_path(POSTGRESQL_INCLUDE_DIR libpq-fe.h
      /usr/include/server
      /usr/include/postgresql
      /usr/include/pgsql/server
      /usr/local/include/pgsql/server
      /usr/include/postgresql/server
      /usr/include/postgresql/*/server
      /usr/local/include/postgresql/server
      /usr/local/include/postgresql/*/server
      $ENV{ProgramFiles}/PostgreSQL/*/include/server
      $ENV{SystemDrive}/PostgreSQL/*/include/server
   )

   find_library(POSTGRESQL_LIBRARY NAMES pq libpq
      PATHS
      /usr/lib
      /usr/local/lib
      /usr/lib/postgresql
      /usr/lib64
      /usr/local/lib64
      /usr/lib64/postgresql
      $ENV{ProgramFiles}/PostgreSQL/*/lib/ms
      $ENV{SystemDrive}/PostgreSQL/*/lib/ms
   )
endif()

[jmckenna]

@offroad-bis to be very honest I don't know if this ticket is a question (if so, then definitely the first step should always be to send to the mapserver-users lists where literally thousands of eyes are waiting to help you) or if you are trying to report an issue (which is the purpose of this issue tracker).

Personally for cmake my command includes -DPOSTGRESQL_LIBRARY=/usr/local/pgsql/lib/libpq.so and I don't have issues. I imagine the first response from the readers there will be asking for your exact cmake command used. But in that case, then this definitely should be sent directly to the mapserver-users list. Maybe also there are more chances of MacOS users who can answer your questions.

Finally, we are always open to accepting pull requests, and improving the FindPostgreSQL.cmake file that you referenced. If you feel like tackling that, that would be great, so that your MacOS environment builds fine.

[offroad-bis]

A pull request was where I was heading. However, I did not want to make a pull request that changed the intent of the FindPostgreSQL.cmake file as it is written. I just wanted clarification on the intent.

Right now, FindPostgreSQL.cmake may find the pg_config executable that is in your path and then ignore its output when it looks for the libpq.so library. This led to my confusion where the libpq.so that ended up being used during compile time was not the one that I expected.

In my case, it found an older version that was not compatible with scram-sha256 authentication. I ran into the problem when Mapserver could not connect to a PostgreSQL 13 database using scram-sha256 authentication. The issue was discussed on the mapserver-users-list with the subject Re: [mapserver-users] PostgreSQL authentication method.

This problem can be avoided by doing what you suggest and specifically set up my cmake command to include the location of the library. I just thought it may be better to use the path specified by pg_config since that executable is one of the first things FindPostgreSQL.cmake looks for. I can create a pull request to do so or I can close this and manually specify the library.

[rouault]

Was the intended action to use the library and include directories specified by the pg_config executable? If so, should the if block for PG_CONFIG be changed so that, when pg_config is found, it searches only the libraries and include paths output by pg_config.

That sounds very reasonable to me.

[jmckenna]

Fixed by @offroad-bis through #6269