codeblocks @20.03: error: Could not find a version of the library!

[ryandesign (Ryan Carsten Schmidt)]

On both arm64 builders (and not on the x86_64 builders):

• ​https://build.macports.org/builders/ports-11_arm64-builder/builds/64911/steps/install-port/logs/stdio
• ​https://build.macports.org/builders/ports-12_arm64-builder/builds/62681/steps/install-port/logs/stdio

configure: error: Could not find a version of the library!

I don't know what library it's referring to.

[ryandesign (Ryan Carsten Schmidt)]

It must be boost. The ​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 ​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.

[ryandesign (Ryan Carsten Schmidt)]

In d60b11f67597bd812b79b4da07a3dde5345ba68d/macports-ports (master):

codeblocks: Update config.guess/config.sub for arm

Closes: #65813

[kencu (Ken)]

a similar error is killing the i386 build of codeblocks and codeblocks-devel:

​https://build.macports.org/builders/ports-10.6_i386-builder/builds/86928/steps/install-port/logs/stdio

​https://build.macports.org/builders/ports-10.6_i386-builder/builds/89302/steps/install-port/logs/stdio

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/i386-darwin10.8.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!

yet boost176 is available for i386

​https://build.macports.org/builders/ports-10.6_x86_64-builder/builds/120861

and the system is being properly recognized:

checking build system type... i386-apple-darwin10.8.0
checking host system type... i386-apple-darwin10.8.0
checking target system type... i386-apple-darwin10.8.0

so it must be something a bit different.

[kencu (Ken)]

the libs are here:

/opt/local/libexec/boost/1.76/lib/libboost_atomic-mt.dylib

It looks like the search algorithm might not be considering that the build is done on an i386 system:

    AS_CASE([${host_cpu}],
      [x86_64],[libsubdirs="lib64 libx32 lib lib64"],
      [ppc64|s390x|sparc64|aarch64|ppc64le],[libsubdirs="lib64 lib lib64"],
      [libsubdirs="lib"],
    )

    dnl allow for real multi-arch paths e.g. /usr/lib/x86_64-linux-gnu. Give
    dnl them priority over the other paths since, if libs are found there, they
    dnl are almost assuredly the ones desired.
    AS_CASE([${host_cpu}],
      [i?86],[multiarch_libsubdir="lib/i386-${host_os}"],
      [multiarch_libsubdir="lib/${host_cpu}-${host_os}"]
    )

but you can override the search algorithm completely by specifying the boost you want with this --with-boost=${prefix}/libexec/boost/1.76 and there is also --with-boost-libdir if that is needed.

[ryandesign (Ryan Carsten Schmidt)]

[349d031cc13380b74cee5ac14d8916a9e3a82a32/macports-ports]