Cannot build or run on Big Sur

[nanoscopic]

This repo cannot be built or run on Big Sur.

It cannot be built due to changes in how CoreFoundation and IOKit frameworks are used.
They are no longer linked directly according to what I'm reading and dlopen must be used.
There is also an error linking the "System" library.

I tried running the latest release and that doesn't work either.

Example output trying to just list devices:

user@users-Mac-mini ios % ./iOSConsole -l
Currently connected devices: (1)
SDMMD__CreateDataFromFileContents: Could not lstat.
SDMMD__CreateDictFromFileContents: Could not read from file.
SDMMD__CreateDataFromFileContents: Could not lstat.
SDMMD__CreateDictFromFileContents: Could not read from file.
1) [my device udid] : B (Invalid) (USB)

Trying to do anything with my device does not work.

[fbartho]

I cloned this repo then:
git submodule init && git submodule update

Then of the targets in the Makefile core, static, openssl, iosconsole all built fine.

Issue 1:

(Not matching what @nanoscopic posted above!)

$ ./build/iOSConsole -l
Currently connected devices: (0)

Note: unfortunately this is wrong -- as I do have a device connected, and the System Console is indeed running / displaying console logs from my device

Issue 2

Unfortunately, make framework fail to link with the following error:

# [output snipped]
xcrun libtool -dynamic -lssl -lcrypto -framework CoreFoundation -lSystem -framework IOKit -lCore -Lbuild/ ./Framework/src/SDMMD_AFCConnection_Class.o ./Framework/src/SDMMD_AFCOperation_Class.o ./Framework/src/SDMMD_AFC_Types.o ./Framework/src/SDMMD_AMAuthInstall.o ./Framework/src/SDMMD_AMAuthInstallApImg3.o ./Framework/src/SDMMD_AMAuthInstallApImg4.o ./Framework/src/SDMMD_AMAuthInstallMonet.o ./Framework/src/SDMMD_AMDevice.o ./Framework/src/SDMMD_AMDevice_Class.o ./Framework/src/SDMMD_AppleFileConduit.o ./Framework/src/SDMMD_Applications.o ./Framework/src/SDMMD_Connection.o ./Framework/src/SDMMD_Connection_Class.o ./Framework/src/SDMMD_Debugger.o ./Framework/src/SDMMD_Error.o ./Framework/src/SDMMD_FileRelay.o ./Framework/src/SDMMD_Functions.o ./Framework/src/SDMMD_Initialize.o ./Framework/src/SDMMD_MCP.o ./Framework/src/SDMMD_MCP_Class.o ./Framework/src/SDMMD_MDFUModeDevice.o ./Framework/src/SDMMD_MRUSBDevice.o ./Framework/src/SDMMD_MRecoveryModeDevice.o ./Framework/src/SDMMD_MRestorableDevice.o ./Framework/src/SDMMD_MRestoreModeDevice.o ./Framework/src/SDMMD_MobileBackup2.o ./Framework/src/SDMMD_Notification.o ./Framework/src/SDMMD_SSL_Functions.o ./Framework/src/SDMMD_Service.o ./Framework/src/SDMMD_USBMuxListener.o ./Framework/src/SDMMD_USBMuxListener_Class.o ./Framework/src/SDMMD_USBMuxListener_Types.o ./Framework/src/SDMMD_USBMux_Protocol.o -o build/libSDMMobileDevice.dylib
ld: framework not found CoreFoundation
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: internal link edit command failed
make: *** [framework] Error 1

Browsing the internet does indeed suggest that at least during the beta-time, that Big Sur had hidden the Filesystem representations of those libraries, such that dlopen was required.

I'm beyond shocked that that might be the case though. If there's an easy way to do this, I would try to build this using an Xcode project, and see if Xcode knows how to link CoreFoundation the framework -- maybe the paths / discovery technique have to be updated from the old manner?

[samdmarshall]

There has to be a way outside of an Xcode project file to link against system libraries, if there is a problem with the makefile it is that i'm using the default search paths provided by the linker, which, seems like should just work.

[fbartho]

@samdmarshall -- I totally agree, I just wonder if there's some stupid flag we have to use that Xcode knows about. -- Like hypothetically a flag that tells the linker what "default" search path to use and that the current default no longer contains CoreFoundation.

[zorgiepoo]

A sample dylib project in Xcode invokes clang -dynamiclib which appears to work here I think (instead of libtool -dynamic; maybe it didn't get updated or something)

[samdmarshall]

invoking clang means you are using the driver, not the actual linker tool, so i assume this means there is some new flag or combination of flags it wants to be used.