Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#64150 closed defect (fixed)

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

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: mamoll (Mark Moll)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: bigsur Cc:
Port: fcl, libccd

Description

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

Change History (12)

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

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

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

Port: libccd added

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:

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.

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

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

comment:6 Changed 3 years ago by mamoll (Mark Moll)

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

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

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

Version 0, edited 3 years ago by mamoll (Mark Moll) (next)

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

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

Resolution: fixed
Status: assignedclosed

comment:11 Changed 3 years ago by mamoll (Mark Moll)

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

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

Note: See TracTickets for help on using tickets.