fcl @0.7.0: No rule to make target `.../libm.tbd', needed by `lib/libfcl.0.7.0.dylib'

[ryandesign (Ryan Carsten Schmidt)]

fcl does not build, with the weird error:

make[2]: *** No rule to make target `/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib/libm.tbd', needed by `lib/libfcl.0.7.0.dylib'.  Stop.

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

[mamoll (Mark Moll)]

The file /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib/libm.tbd doesn't exist on my machine either. When I compile fcl with sudo port -dv destroot fcl locally on my machine, I see that libfcl is linked against /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libm.tbd, which does exist. I have an Intel-based MacBook Pro. I wonder what else could explain the error.

[kencu (Ken)]

The (incorrect) path is (incorrectly) burned into the cmake files of the libccd port.

In this file:

ccd-targets-macports.cmake

we have:

set_target_properties(ccd PROPERTIES
  IMPORTED_LINK_INTERFACE_LIBRARIES_MACPORTS "/Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib/libm.tbd"

and that gets picked up by fcl during it's build.

Yet another example of the errors of burning in the path to the SDK in installed files.

[ryandesign (Ryan Carsten Schmidt)]

Thanks, Ken, I was just about to write the same.

The packages for libccd for Big Sur were built in November and December of last year:

• ​http://packages.macports.org/libccd/libccd-2.1_0.darwin_20.x86_64.tbz2
• ​http://packages.macports.org/libccd/libccd-2.1_0.darwin_20.arm64.tbz2

At that time, the current version of MacPorts was 2.6.4, and it had a flawed understanding of how Apple had changed the macOS version numbering scheme starting with version 11. In addition, Apple was publishing Xcode versions and command line tools releases that only contained major.minor versions of SDKs: they only offered the "11.0" SDK. They did not offer an "11" SDK. So MacPorts used the "11.0" SDK. Of course, in future versions of Xcode and the CLT, there would be no "11.0" SDK; instead there would be an "11.1" SDK, "11.3" SDK, etc. Eventually, Apple would see the flaw in this and started offering an "11" SDK symlink pointing to whatever the current 11.x SDK was. MacPorts 2.7.0 and later use that instead if it exists.

The libccd port should be fixed to stop burning the SDK path into itself. If that can't be done, its revision could simply be increased, which should cause it to burn the "11" SDK path into itself, which should work fine on any recent macOS 11-compatible CLT version.

[mamoll (Mark Moll)]

I don't see anything that looks "off" in the cmake code that generates that file: ​https://github.com/danfis/libccd/blob/v2.1/src/CMakeLists.txt. Unless either one of you sees a fix, I am tempted to just bump the revision for libccd.

[kencu (Ken)]

You might consider stripping the whole "libm" link out of the libccd files altogether, as it is a waste of time on darwin and just causes trouble:

$ ls -la /usr/lib/libm.dylib
lrwxr-xr-x  1 root  wheel  15  5 Aug 13:07 /usr/lib/libm.dylib -> libSystem.dylib

[mamoll (Mark Moll)]

@kencu is libm not needed on any version of Darwin?

[kencu (Ken)]

I think libm.dylib has always been a symlink to libSystem.dylib ... I can go back as far as SnowLeopard at the moment:

$ uname -a
Darwin KensMacBookPro.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

$ ls -la /usr/lib/libm.dylib
lrwxr-xr-x  1 root  wheel  15 25 Feb  2015 /usr/lib/libm.dylib -> libSystem.dylib

[mamoll (Mark Moll)]

Ok, fixed libccd, ​https://github.com/macports/macports-ports/commit/b1dc4df2c0a8a0ff414c07e9e1775b0efad77d8d. Now, how do I trigger a rebuild of fcl again? I have an account on build.macports.org.

[ryandesign (Ryan Carsten Schmidt)]

I've scheduled new fcl builds for you. To do so yourself in the future, if you want to schedule builds on several builders, the easiest way is at ​https://build.macports.org/builders. Scroll down to Force Selected Builds, portwatcher_force, click the checkboxes for which builders you want, fill the port name(s) into the Port list field, enter a brief explanation of the reason into the reason field, and click Force Build. If you want to do it on all builders, you can scroll further down to Force All Builds, portwatcher_force.

[mamoll (Mark Moll)]

Thanks, @ryandesign. That info might be useful to add to ​https://guide.macports.org/#project.

[ryandesign (Ryan Carsten Schmidt)]

There seems to be close to no information about the buildbot in the guide. Improvements to the guide are of course welcome.