[MacPorts] #65813: codeblocks @20.03: error: Could not find a version of the library!

[MacPorts]

#65813: codeblocks @20.03: error: Could not find a version of the library!
-------------------------+--------------------
  Reporter:  ryandesign  |      Owner:  (none)
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.7.2
Resolution:              |   Keywords:  arm64
      Port:  codeblocks  |
-------------------------+--------------------

Comment (by ryandesign):

 It must be boost. The [https://build.macports.org/builders/ports-
 12_x86_64-builder/builds/40684/steps/install-port/logs/stdio successful
 12_x86_64 build] says:

 {{{
 checking for boostlib >=  (102000) includes in
 "/opt/local/libexec/boost/1.76/include"... yes
 checking for boostlib >=  (102000) lib path in
 "/opt/local/libexec/boost/1.76/lib/x86_64-darwin21.3.0"... no
 checking for boostlib >=  (102000) lib path in
 "/opt/local/libexec/boost/1.76/lib64"... no
 checking for boostlib >=  (102000) lib path in
 "/opt/local/libexec/boost/1.76/libx32"... no
 checking for boostlib >=  (102000) lib path in
 "/opt/local/libexec/boost/1.76/lib"... yes
 checking for boostlib >=  (102000)... yes
 checking whether the Boost::System library is available... yes
 }}}

 while the [https://build.macports.org/builders/ports-
 12_arm64-builder/builds/62681/steps/install-port/logs/stdio unsuccessful
 12_arm64 build] says:

 {{{
 checking for boostlib >=  (102000) includes in
 "/opt/local/libexec/boost/1.76/include"... yes
 checking for boostlib >=  (102000) lib path in
 "/opt/local/libexec/boost/1.76/lib/arm-darwin21.3.0"... no
 checking for boostlib >=  (102000)... yes
 checking whether the Boost::System library is available... yes
 configure: error: Could not find a version of the library!
 }}}

 Why doesn't it continue looking in /opt/local/libexec/boost/1.76/lib on
 arm64?

 In the codeblocks file m4/ax_boost_base.m4 I see:

 {{{
     AC_REQUIRE([AC_CANONICAL_HOST])
     dnl On 64-bit systems check for system libraries in both lib64 and
 lib.
     dnl The former is specified by FHS, but e.g. Debian does not adhere to
     dnl this (as it rises problems for generic multi-arch support).
     dnl The last entry in the list is chosen by default when no libraries
     dnl are found, e.g. when only header-only libraries are installed!
     AS_CASE([${host_cpu}],
       [x86_64],[libsubdirs="lib64 libx32 lib lib64"],
       [ppc64|s390x|sparc64|aarch64|ppc64le],[libsubdirs="lib64 lib
 lib64"],
       [libsubdirs="lib"],
     )
 }}}

 So it should look in lib on aarch64 systems, but it doesn't realize this
 is an aarch64 system because configure is detecting it as arm instead:

 {{{
 checking build system type... arm-apple-darwin21.3.0
 checking host system type... arm-apple-darwin21.3.0
 checking target system type... arm-apple-darwin21.3.0
 }}}

 codeblocks ships with config.guess and config.sub files dated 2019, which
 predates the introduction of Apple Silicon processors. Maybe updating
 those files from automake would help.

 In fact, shouldn't the last line of the `AS_CASE` statement cause the lib
 directory to be searched on all other unrecognized systems? That doesn't
 appear to be happening.

-- 
Ticket URL: <https://trac.macports.org/ticket/65813#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS