I have a linker error when using Gluon to deploy to iOS.
Following the instructions in gluon-samples/HelloSharedLib and the instructions in the Gluon Documentation. I have the following versions installed. We have a paid Apple Developer account.
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /opt/homebrew/Cellar/maven/3.8.6/libexec
Java version: 17.0.3, vendor: GraalVM Community, runtime: /Library/Java/JavaVirtualMachines/graalvm-svm-java17-darwin-m1-gluon-22.1.0.1-Final/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.0.1", arch: "aarch64", family: "mac"
Xcode 14.2, Build version 14C18
I can build using mvn gluonfx:sharedlib without an issue on both arm64 and x86 Macs, but when I build with the -Pios flag the linking step fails with the following output (on both machines):
Process
=======
link
Command Line
============
clang /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/gvm/HelloSharedLib/dummy.o /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/gvm/tmp/SVM-1675269285429/hello.hellosharedlib.o -ljava -lnio -lzip -lnet -lprefs -ljvm -lfdlibm -lz -ldl -lj2pkcs11 -ljaas -lextnet -lstdc++ -w -fPIC -arch arm64 -mios-version-min=11.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS16.2.sdk -shared -undefined dynamic_lookup -lpthread -llibchelper -lffi -ldarwin -Wl,-framework,Foundation -Wl,-framework,UIKit -Wl,-framework,CoreGraphics -Wl,-framework,MobileCoreServices -Wl,-framework,OpenGLES -Wl,-framework,CoreText -Wl,-framework,QuartzCore -Wl,-framework,ImageIO -Wl,-framework,CoreBluetooth -Wl,-framework,CoreImage -Wl,-framework,CoreLocation -Wl,-framework,CoreMedia -Wl,-framework,CoreMotion -Wl,-framework,CoreVideo -Wl,-framework,Accelerate -Wl,-framework,AVFoundation -Wl,-framework,AudioToolbox -Wl,-framework,MediaPlayer -Wl,-framework,UserNotifications -Wl,-framework,ARKit -Wl,-framework,AVKit -Wl,-framework,SceneKit -Wl,-framework,StoreKit -Wl,-framework,ModelIO -Wl,-framework,WebKit -o /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/HelloSharedLib.dylib -L/Library/Java/JavaVirtualMachines/graalvm-svm-java17-darwin-m1-gluon-22.1.0.1-Final/Contents/Home/lib/svm/clibraries/27/ios-arm64 -L/redacted/path/.gluon/substrate/javaStaticSdk/18-ea+prep18-8/ios-arm64/staticjdk/lib/static
Output
======
ld: framework not found UIKit
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
The only other lines in the log file that may be relevant are;
[Wed Feb 01 17:35:08 CET 2023][FINE] PB Command for compile-additional-sources: clang -c -DSUBSTRATE -xobjective-c -arch arm64 -mios-version-min=11.0 -I/Library/Java/JavaVirtualMachines/graalvm-svm-java17-darwin-m1-gluon-22.1.0.1-Final/Contents/Home/include -I/Library/Java/JavaVirtualMachines/graalvm-svm-java17-darwin-m1-gluon-22.1.0.1-Final/Contents/Home/include/darwin -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS16.2.sdk -DGVM_17 -I/redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/gvm/HelloSharedLib dummy.c
[Wed Feb 01 17:35:08 CET 2023][FINE] Start process compile-additional-sources...
[Wed Feb 01 17:35:08 CET 2023][FINE] Result for compile-additional-sources: 0
Does anyone know the resolution?
Removing some offending frameworks will allow clang to create the library, but it will fail to link on deployment to the physical device.
dyld[21677]: Library not loaded: /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/HelloSharedLib.dylib
Referenced from: <621E3E84-DB84-30F0-AB2A-74B6EEECA791> /private/var/containers/Bundle/Application/2321AEDA-A346-4C64-9657-617BB6AF6C14/Runner.app/Runner
Reason: tried: '/usr/lib/system/introspection/HelloSharedLib.dylib' (errno=2, not in dyld cache), '/redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/HelloSharedLib.dylib' (errno=2), '/private/preboot/Cryptexes/OS/redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/HelloSharedLib.dylib' (errno=2), '/redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/HelloSharedLib.dylib' (errno=2), '/usr/local/lib/HelloSharedLib.dylib' (errno=2), '/usr/lib/HelloSharedLib.dylib' (errno=2, not in dyld cache)
If I try to deploy to sim, I get the expected message that the lib was compiled for a different target, so it looks like Xcode is at least trying to link the file.
If I deploy the shared lib for macOS that was built with mvn gluonfx:sharedlib, Xcode successfully links with the HelloSharedLib.dylib, so it seems like the error is in the hack of `clang` to create the dylib.
I checked for the UIKit and it is under the child directory/System/Library/Frameworks
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS16.2.sdk/...
Edit to add verbose output
Homebrew clang version 15.0.3
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
"/usr/bin/ld" -demangle -lto_library /opt/homebrew/Cellar/llvm/15.0.3/lib/libLTO.dylib -dynamic -dylib -arch arm64 -platform_version ios 11.0.0 16.2 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -undefined dynamic_lookup -w -undefined dynamic_lookup -o /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/HelloSharedLib.dylib -L/Library/Java/JavaVirtualMachines/graalvm-svm-java17-darwin-m1-gluon-22.1.0.1-Final/Contents/Home/lib/svm/clibraries/27/ios-arm64 -L/redacted/path/.gluon/substrate/javaStaticSdk/18-ea+prep18-8/ios-arm64/staticjdk/lib/static /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/gvm/HelloSharedLib/dummy.o /redacted/path/github/gluon-samples/HelloSharedLib/target/gluonfx/arm64-ios/gvm/tmp/SVM-1675322770429/hello.hellosharedlib.o -ljava -lnio -lzip -lnet -lprefs -ljvm -lfdlibm -lz -ldl -lj2pkcs11 -ljaas -lextnet -lc++ -lpthread -llibchelper -lffi -ldarwin -framework Foundation -framework UIKit -framework CoreGraphics -framework MobileCoreServices -framework OpenGLES -framework CoreText -framework QuartzCore -framework ImageIO -framework CoreBluetooth -framework CoreImage -framework CoreLocation -framework CoreMedia -framework CoreMotion -framework CoreVideo -framework Accelerate -framework AVFoundation -framework AudioToolbox -framework MediaPlayer -framework UserNotifications -framework ARKit -framework AVKit -framework SceneKit -framework StoreKit -framework ModelIO -framework WebKit -lSystem
ld: framework not found UIKit
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
Solved it.
I've used LLVM installed via brew and set the flags recommended by this installation;
LDFLAGS="-L/opt/homebrew/opt/llvm/lib"
CPPFLAGS="-I/opt/homebrew/opt/llvm/include"
PATH="/opt/homebrew/opt/llvm/bin:$PATH"
These clash with the installation from either Xcode or Gluon (I'm unsure which) and caused the linker error.
I removed the environment variables and restarted and the problem went away.
Thank you José for your help, which ultimately led me to the solution.
Related
I compile a simple boot code on MacOS,But got a ld error :
#ld -Tlink.ld -o kernel.bin start.o main.o scrn.o
ld: unknown option: -Tlink.ld
#ld -T
ld: unknown option: -T
ld version is :
$ ld -v
#(#)PROGRAM:ld PROJECT:ld64-650.9
BUILD 13:09:02 May 28 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 12.0.5, (clang-1205.0.22.11) (static support for 27, runtime is 27)
TAPI support using: Apple TAPI version 12.0.5 (tapi-1205.0.7.1)
I search internet for a while,But no found any useful solution.
How can i link this script successful? Thanks.
I compile a simple boot code on MacOS,But got a ld error :
It looks like you are trying to build a boot loader which assumes GNU tools with native MacOS tools.
You'll need to use appropriate tools instead.
I am getting build errors when I build MacPorts on my iMac running the latest Big Sur beta. Yeah I know, it's beta, but I think my question is still relevant. Please see below for the full error message (first error of many). Thanks for any help!
clang -MM -MP -DHAVE_CONFIG_H -I/Users/rcook/current_projects/macports-base/src -I/Users/rcook/current_projects/macports-base/src -I. -I/Users/rcook/current_projects/macports-base/vendor/vendor-destroot/opt/local/libexec/macports/include -I./../compat access.c > access.d
clang -g -O2 -std=c99 -Wextra -Wall -fPIC -arch arm64 -arch x86_64 -DHAVE_CONFIG_H -I/Users/rcook/current_projects/macports-base/src -I/Users/rcook/current_projects/macports-base/src -I. -I/Users/rcook/current_projects/macports-base/vendor/vendor-destroot/opt/local/libexec/macports/include -I./../compat -c -o access.o access.c
In file included from access.c:36:
In file included from ./darwintrace.h:40:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/pthread.h:55:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_types.h:27:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture
#error Unsupported architecture
So I'm following the GStream tutorial:
https://gstreamer.freedesktop.org/documentation/tutorials/basic/hello-world.html?gi-language=c
I've installed GStreamer 1.16 (tried installing with brew as well as downloading the osx installer from gstreamer website).
When I try to compile the tutorial code on linux:
gcc basic-tutorial-1.c -o basic-tutorial-1 `pkg-config --cflags --libs gstreamer-1.0`
everything works fine, but the same code on my osx fails on missing header files when I try to compile it with gcc or clang:
➜ tutorial gcc basic-tutorial-1.c -o basic-tutorial-1 -L/Library/Frameworks/GStreamer.framework/Versions/1.0/Headers
basic-tutorial-1.c:1:10: fatal error: 'gst/gst.h' file not found
#include <gst/gst.h>
^~~~~~~~~~~
1 error generated.
➜ tutorial cc basic-tutorial-1.c -o basic-tutorial-1 -L/Library/Frameworks/GStreamer.framework/Versions/1.0/Headers
basic-tutorial-1.c:1:10: fatal error: 'gst/gst.h' file not found
#include <gst/gst.h>
^~~~~~~~~~~
1 error generated.
I can see my header files installed:
➜ tutorial ls -lsh /Library/Frameworks/GStreamer.framework/Versions/1.0/Headers/gst/gst.h
8 -rw-r--r-- 1 root wheel 3.7K 20 Apr 01:43 /Library/Frameworks/GStreamer.framework/Versions/1.0/Headers/gst/gst.h
s
So I was able to resolve this, and the solution was:
1. installing both the package and the devel package:
gstreamer-1.0-1.16.0-x86_64.pkg
gstreamer-1.0-devel-1.16.0-x86_64.pkg
from https://gstreamer.freedesktop.org/data/pkg/osx/1.16.0/
I did this when I installed on ubuntu, but not on osx, since, well, I'm just not use to having devel packages on OSX.
compile with -framework GStreamer argument and as #lurker suggested, using a -I flag
Now this compiles successfully:
cc basic-tutorial-1.c -o basic-tutorial-1 -framework GStreamer -I/Library/Frameworks/GStreamer.framework/Versions/1.0/Header
I am trying to compile the minimalist C opengl code in https://github.com/fogleman/HelloGL on my Ubuntu 18.04 system, but I get the following error:
gcc -c -o build/matrix.o -std=c99 -O3 src/matrix.c
gcc -o main build/shader.o build/main.o build/util.o build/matrix.o -lglew -lglfw3 -framework Cocoa
-framework OpenGL -framework IOKit -framework CoreVideo -lm
gcc: error: Cocoa: No such file or directory
gcc: error: OpenGL: No such file or directory
gcc: error: IOKit: No such file or directory
gcc: error: CoreVideo: No such file or directory
gcc: error: unrecognized command line option ‘-framework’
gcc: error: unrecognized command line option ‘-framework’
gcc: error: unrecognized command line option ‘-framework’
gcc: error: unrecognized command line option ‘-framework’
Makefile:24: recipe for target 'main' failed
I do realize the reason for this is the following line in the MakeFIle, which is made for OSX (presumably):
LIBS = -lglew -lglfw3 -framework Cocoa -framework OpenGL -framework IOKit -framework CoreVideo
Is there a way of adapting this line to make it work on a GNU/Linux system?
Or does it need to have to be linked to the Cocoa framework?
I downloaded this example project and tinkered with it myself. It does not appear to contain any OSX-specific code; it's just that its Makefile was written for OSX only.
First make sure you have have the libglfw3-dev and libglew-dev packages installed. Installing these from the Ubuntu package manager should automatically pull in all the other libraries that are required.
Next, change the LIBS line of the Makefile to read
LIBS = -lGLEW -lglfw -lGL -lm
For no apparent reason, the library called libglew on OSX is called libGLEW on (Debian-style) Linux, and the library called libglfw3 on OSX is called libglfw on Linux. -lGL is the Linux equivalent of -framework OpenGL, and -lm brings in the math library (needed for one call to sqrt), which is separate from the core C library on Linux but not on OSX, if I remember correctly.
You may also need to adjust the FLAGS line. This setting worked for me:
FLAGS = -g -O2 -std=gnu99 -Wall -Wextra -Wpedantic
The important change here is -std=gnu99 instead of -std=c99. The stricter c99 mode is troublesome; it disables extensions that people don't realize are extensions, like math.h defining the constant M_PI, which this program wants. (It also has a nasty habit of breaking network-related system headers, for reasons which are too complicated to get into here. Fortunately, this program doesn't use the network.)
I also added -Wall -Wextra -Wpedantic, added -g, and changed -O3 to -O2. These are all things I do habitually to every C program I tinker with. The first two can reveal problems and they almost never hurt; in this case they didn't make any visible difference. The third is because -O3 often makes your program slower than -O2 would have.
The -framework option is specific to Apple platforms, as the Cocoa, IOKit and CoreVideo frameworks themselves. The build commands and options you are using are for macOS it would appear.
I've just upgraded to Xcode 5 beta with the April 15 2013 commandline tools and hit the following warning when running a cmake build during the standard CMakeTestCCompiler.cmake attempt to compile a simple test program:
cmake -version
cmake version 2.8.11.2
ld: building for MacOSX, but linking against dylib built for iOS Simulator file '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/libSystem.dylib' for architecture i386
lipo -info /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/libSystem.dylib
Non-fat file: libSystem.dylib is architecture: i386
The compile step is:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -o /Users/temp/testCCompiler.c.o -c /Users/temp/testCCompiler.c
lipo -info /Users/temp/testCCompiler.c.o
Non-fat file: testCCompiler.c.o is architecture: i386
The link step is:
/usr/local/bin/cmake -E cmake_link_script /Users/temp/link.txt --verbose=1
where link.txt contains:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -Wl,-headerpad_max_install_names /Users/temp/testCCompiler.c.o -o testCCompiler
It seems that both testCCompiler.c.o and libSystem.dylib are i386, i386 is specified in link.txt, and i386 is the right architecture for the simulator so i'm not sure why it thinks it is building for MacOSX. Perhaps a commandline option is wrong :(.
thanks for any help!
The problem was that Xcode 5 replaces gcc with clang and adds in a "-triple" option that specifies OSX as the target. If you pass "-miphoneos-version-min=7.0" on both gcc command lines it works. You can see the clang command line if you pass "--verbose" to gcc. It's also necessary to add to the PATH for Xcode 5 so that cmake can find the necessary tools: export PATH=/Applications/Xcode5-DP6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode5-DP6.app/Contents/Developer/usr/bin:$PATH None of this is official.. but works for me so far.
run this comment on your client.app:
export PATH=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:$PATH