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.
Related
I have followed the instructions provided for installing the GSL-1.16 library and I think I have successfully installed the library. However when I try to compile & run the example program found in the website (http://www.gnu.org/software/gsl/manual/html_node/An-Example-Program.html#An-Example-Program) I get the following message:
$ gcc besel_exam.c
Undefined symbols for architecture x86_64:
"_gsl_sf_bessel_J0", referenced from:
_main in besel_exam-72d841.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The operating system is macOS X Yosemite and the output of gcc --version is the following:
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
Indeed, as #trojanfoe and #bergercookie said you have to compile your file and then link it to the library. As explained in compile and link, for that particular example:
First compile the file:
gcc -Wall -I/usr/local/include -c example.c -o example.o
second, link it to the library:
gcc -L/usr/local/lib example.o -lgsl -o example.e
where of course, /usr/local/lib should be replaced for the path where you have gsl installed.
EDIT: in macOS, from Yosemite the default location for the installation is /opt/local/lib (and /opt/local/include)
I just installed MPICH on my mac with brew. And I'm trying to compile code.
MacBook-Air:~ ali$ cd Desktop/mpitest
MacBook-Air:mpitest ali$ mpicc mpi_prime.c -o mpi_prime
ld: file not found: /usr/local/lib/gcc/4.9/libgfortran.3.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I tried mpiexec hostname and it works just fine.
Thank you.
I have the same problem as #tfb785, but his solution did not work for me. I already had gcc 4.9.2_1 and 5, but I had to tell brew to switch between the versions:
brew switch gcc 4.9.2_1
The Problem is that the switch from gcc 4.9 to gcc 5 break path to the Fortran 3 lib. I have the same problem with R:
metalpro2:~ mirkoebert$ R
dyld: Library not loaded: /usr/local/lib/gcc/4.9/libgfortran.3.dylib
Referenced from: /usr/local/Cellar/r/3.2.0/R.framework/Versions/3.2/Resources/lib/libR.dylib
Reason: image not found
Trace/BPT trap: 5
R references the Fortran 3 lib in the gcc 4 directory.
The solution with brew:
you need gcc 4.9 and 5.X, installed via brew
link your new lib into the old gcc folder:
ln -s /usr/local/lib/gcc/5/libgfortran.3.dy lib/usr/local/lib/gcc/4.9/libgfortran.3.dylib
Now it works for R.
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
Following the instructions given here, I’ve downloaded the latest version of OpenSSL (openssl-1.0.1e.tar.gz) from here and installed it on Ubuntu v12.10 (32-bit).
I have a C project in Eclipse CDT (v1.2.0.201212170456) that statically links to the following two .a files:
home/usr/local/ssl/lib/libcrypto.a
home/usr/local/ssl/lib/ libssl.a
However when I build my project I get these errors:
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: skipping incompatible /usr/local/ssl/lib/libssl.a when searching for -lssl
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/../../../../arm-none-linux-gnueabi/bin/ld: cannot find –lssl
My toolchain is CodeSourcery (Sourcery G++ Lite 2010q1-202) and is for 32-bit OS.
What am I doing wrong?
Compiler command line I'm using:
arm-none-linux-gnueabi-gcc -I"/path to my/include" -O0 -g3 -Wall -c -fmessage-length=0 -v -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"
You have installed OpenSSL on an Ubuntu 32-bit machine (assuming x86), but are trying to link it to an ARM binary:
/home/tashimaya/Applications/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi: your ARM toolchain
/usr/local/ssl/lib/libssl.a: a 32-bit x86 version of OpenSSL
You will have to cross-compile OpenSSL for ARM using your ARM toolchain (i.e.: arm-none-linux-gnueabi-gcc), then you will be able to link it to an ARM binary.
It says that /usr/local/ssl/lib/libssl.a is not in the size expected. Try file on it to check if you compiled it in 32 or 64 bit version. And check how you are compiling your own program too. If both matches linker (ld) will link it fine.
If you compile your program into 64 bit and link it with libssl.a in 32 bit, this will not work
example:
file a.out
/* kind ofoutput */ a.out: Mach-O 64-bit executable x86_64
http://unixhelp.ed.ac.uk/CGI/man-cgi?file
I am trying to use the function EC_KEY_new_by_curve_name(NID_secp256k1) present in openssl. However, when I compile, I get the following error:
undefined symbols for architecture x86_64:
"_EC_KEY_new_by_curve_name", referenced from:
CKey::CKey() in bitcoin.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I have been hinted that macos openssl is not compile with the ECC extensions. Is the problem? If so, how do I correct it?
If you're using the OpenSSL library that comes with MacOS SDK, then it should automatically have 64-bit support built in.
Looking at the first hit on Google, I'm wondering if you are just not including the correct library in your XCode project. Did you get -lcrypto into the project settings, or forget to add libCrypto.dylib to your list of libraries in the project?
On my SnowLeopard (10.6) machine, I see the symbols are defined in libCrypto:
[/usr/lib]:; nm -arch x86_64 libcrypto.0.9.8.dylib | egrep -i new_by_curve
00000000000a4ac0 T _EC_GROUP_new_by_curve_name
00000000000ab540 T _EC_KEY_new_by_curve_name