Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#65813 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: ryandesign (Ryan Carsten Schmidt)
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: arm64 Cc:
Port: codeblocks

Description

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

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

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

Change History (5)

comment:1 Changed 2 years ago by 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.

comment:2 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: set to ryandesign
Resolution: fixed
Status: newclosed

In d60b11f67597bd812b79b4da07a3dde5345ba68d/macports-ports (master):

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

Closes: #65813

comment:3 Changed 2 years ago by 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.

comment:4 Changed 2 years ago by 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.

Note: See TracTickets for help on using tickets.