Topic: Unable to link x86_64 versions of libraries with Xcode newer than 15 beta 2

[kode54]

As the topic says, I cannot link the x86_64 architecture with version 15 beta 3 or newer. All of them report missing symbols from the libraries.

Worse still, all of the plugins I've downloaded, (FLAC, MPC, Opus, WavPack), report the following if I attempt to import them at link time instead of letting BASS import them:

ld: malformed mach-o missing relocations, LC_DYLD_INFO, or LC_DYLD_CHAINED_FIXUPS in '/Users/chris/Downloads/bass/libbass_mpc.dylib'

Edit: This appears to be a regression in Xcode 15 beta 3 and newer. Downgrading to beta 2 fixes the problem.

[Ian @ un4seen]

I haven't tried Xcode 15 yet, so thanks for the heads-up. I'll look into it. If it turns out to not just be a bug in the Xcode beta (won't be fixed in the final release), then I guess it may be that the BASS libraries need to be rebuilt with a newer Xcode version and/or target a higher macOS version. The x86_64 arch is currently built with Xcode 8 (the same as the i386 arch) to support all macOS versions back to 10.5. I notice that targetting 10.6 adds a LC_DYLD_INFO_ONLY load command to the dylibs, which perhaps will prevent the ld message mentioning LC_DYLD_INFO. If you would like to try them, here are x86_64 BASS and BASS_MPC builds targetting 10.6:

   www.un4seen.com/stuff/bass-osx-x64.zip

[kode54]

Yes, that fixes the linking for those two libraries. Looks like Xcode 15 has moved the minimum build target for linking in x86_64, then.

[Ian @ un4seen]

Good to hear that simply targeting 10.6 instead of 10.5 fixes the problem. I think I'll wait to see if the problem is still present with the Xcode 15 final release, before rebuilding all of the libraries if necessary. Let me know if you need any particular add-ons rebuilt for testing with the Xcode 15 beta in the meantime.

[kode54]

Not sure I'll be using Xcode 15 for my released builds anyway, as it results in NIB initialization of objects crashing on some of my Swift code, and only on 10.13 and 10.14, but not 10.15 and up.

[kode54]

Official word from Apple is that they're not doing anything different because you're willing to recompile the libraries.

[DEROM]

The new version of Xcode and CommandLineTools has been officially released. Now, version 15.0 is no longer in beta; it's the standard Xcode available on the App Store. It still retains the issue with library linking. The solution discussed in this thread helps with library linking, including the library at https://www.un4seen.com/stuff/bass-osx-x64.zip. It seems that this version is not signed because when it is used, the system issues a warning and refuses to launch the linked application (without special permission from system settings)

[Klaus]

Using the newly released Xcode 15.0 I experience the same issue: https://www.un4seen.com/stuff/bass-osx.zip from August 15th does not link for x86_64 while arm64 contained in the same dylib links without any problems. The x84_64 only dylib contained in https://www.un4seen.com/stuff/bass-osx-x64.zip from August 1st links with Xcode 15.0 as reported before, however I could not test it, since I am also using libbassflac.dylib and libtags.dylib resulting in undefined symbols errors from libtags for x86_64. Seems like there is a need to rebuild all dylibs including arm64 and x86_64. Maybe i386 is not needed any more, since it is deprecated.

[Klaus]

Additional Info: Adding -ld64 (or -ld_classic) to Build Settings -> Linking - General -> Other Linker Flag solves the x86_64 linking issue (see https://developer.apple.com/forums/thread/731089), BUT the successfully compiled App crashes on my intel Mac running macOS 10.13.4:

Dyld Error Message:
  Library not loaded: @rpath/libswiftAppKit.dylib
  Referenced from: [...]
  Reason: Incompatible library version: [...] requires version 45.0.0 or later, but libswiftAppKit.dylib provides version 1.0.0

Not sure if this is caused by using the old linker -ld_classic or another issue with Xcode 15.0.

[Ian @ un4seen]

That "-ld64" option is an interesting find, although that link seems to be regarding a different issue with iOS apps? Still, even if it does help, it isn't ideal to require special linker options, so it seems like the macOS BASS libraries will need to be rebuilt (I was hoping not!). I'll look into that. For now, here are rebuilds of BASS and BASSFLAC that include all architectures (not only x86_64) which you can replace the current releases with (use the BASS package's makefile to remove i386 for app store releases):

   www.un4seen.com/stuff/bass-osx.zip
   www.un4seen.com/stuff/bassflac-osx.zip

A new TAGS add-on version was actually released earlier this week, including the x86_64 target change, so you can get that from the BASS webpage. Let me know if you need any others urgently, or if you have any problems with these.

[Klaus]

@DEROM: I don't think that Ian is signing his dylibs. You need to have a developper license and pay for it:-( Seems like Apple changed someting with Xcode 15. Quoted from https://developer.apple.com/forums/thread/715385:
"Historically there was no need to code sign libraries in SDKs. If you shipped an SDK to another developer, they were responsible for re-signing all the code as part of their distribution process. Xcode 15 beta changes this. You should sign your SDK so that a developer using it can verify this dependency."

@Ian: I will check with your new dylibs and let you know if the App is running on my intel Mac without signatre warnings as reported by DEROM.

[Klaus]

Using www.un4seen.com/stuff/bass-osx.zip, www.un4seen.com/stuff/bassflac-osx.zip, and Tags 19:

Compiling Xcode 15 Debug for arm64, running on M1 mac:
Linking OK, but runtime error "Library not loaded: @loader_path/libtags.dylib" although libtags.dylib has been signed and embedded in *.app/Contents/Frameworks/
(old Tags 18 can be loaded at runtime)

Compiling Xcode 15 Release for x86_64 and arm64, running on intel mac:
Linking OK, but same runtime error with libtags.dylib from Tags 19
(old Tags 18 does not link)

Seems like you used different settings for @loader_path when building libbass and libtags.

PS: No urgent problems from my side, I can use Xcode 14.3.1 instead of Xcode 15.0 for a while.

[Ian @ un4seen]

Oops! The latest TAGS add-on release's install path had the old "@loader_path" setting instead of "@rpath" (which has been used since BASS 2.4.17). That has been corrected now, so please re-download and see if you still have any trouble with it.

Btw, in case you have any old add-ons that you want to still use for any reason, you can convert them from "@loader_path" to "@rpath" by running "make rpath" with the makefile in the BASS package.

[Klaus]

With the updated Tags 19:

Building Xcode 15.0 Release for x86_64 and arm64:
Linking: OK
Running on M1 mac: OK
Running on intel mac with macOS 10.13: Crashing with
Library not loaded: @rpath/libswiftAppKit.dylib
Reason: Incompatible library version: [...] requires version 45.0.0 or later, but libswiftAppKit.dylib provides version 1.0.0

But this is not a BASS issue and I could fix that with the "Other Linker Flag" proposed in https://github.com/apple/swift/issues/68163 resulting in an App that runs on macOS 10.13 the same way as if compiled with Xcode 14.

So Xcode 15 claims to be able to build for macOS 10.13 but it does not without usings workarounds. New Xcode, new fun...

If the App refuses to start due to signature issues I cannot verify. Actually it started without any problems, but I do not remember if I already gave special permission in system settings before.

[Ian @ un4seen]

All the rebuilt macOS libraries are up now on the BASS page. Note the BASS build posted above is a newer version, including some tweaks, so you may want to continue using that instead of the current release version.