I am trying to weak-link to the Security framework in Mac OS X (10.8.2, Darwin Kernel Version 12.2.1). It appears that the linker is simply not recognizing the '-weak_framework' tag.
This is the linker error I get -
[cc] Starting link
[cc] i686-apple-darwin11-llvm-gcc-4.2: Security: No such file or directory
What I found interesting (and hence the reason I believe the '-weak_framework' tag isn't recognized), is that when I change '-weak_framework' to '-thisisgarbage', I still get the same error.
I am running an Ant build script, so this is what's in there -
<linkerarg value="-weak_framework" />
<linkerarg value="Security" />
Any input is greatly appreciated.
That command line option is actually for ld (see manpage), not gcc. You can pass ld command line options via gcc using the -Wl, flag; so I would expect your <linkerarg> to look like this:
<linkerarg value="-Wl,-weak_framework,Security" />
But you might have to mess about with the quotes to get that quite right...
Related
when i run a command in terminal (Using El Capitan)
ld -m elf_i386 -T linker.ld -o kernel kasm.o kc.o
It shows the following error :
ld: warning: option -m is obsolete and being ignored
ld: file not found: elf_i386
Can anybody help me with this?
when i run a command in terminal
You are trying to link some kind of kernel using ld directly. This is actually one of very few cases where using ld directly is appropriate.
However, the command line arguments you give to ld assume that you are using GNU-ld (you may have copied them from a Linux tutorial), but you are not using GNU-ld, you are using MacOS native linker, which doesn't understand these arguments.
Can anybody help me with this?
Please ask a separate question, along the lines of "I am trying to build XXX on MacOS, following tutorial YYY, and don't understand how to adjust this Linux command to Mac OS".
Note that it may not be possible to build XXX on MacOS at all. In particular, the ld manpage does not mention ELF as possible output, so if your "build XXX" goal includes building an ELF kernel, you'll likely need to build a cross-linker (a GNU-ld linker which runs on Mac OS (i.e. hosted on Mac OS), but produces code for ELF target.
The command clang -fuse-ld=bfd returns error, saying invalid linker name in argument -fuse-ld=bfd.
I have tried bfd, lld and ld. It seems that only ld is correct.
But, in my mind, ld is the general term for the linker and does not refer to a specific linker (ld.bfd on Linux).
So I wonder that which linker does macOS actually use?
macOS uses Apple's own linker, ld64. The source is available here.
when i run a command in terminal (Using El Capitan)
ld -m elf_i386 -T linker.ld -o kernel kasm.o kc.o
It shows the following error :
ld: warning: option -m is obsolete and being ignored
ld: file not found: elf_i386
Can anybody help me with this?
when i run a command in terminal
You are trying to link some kind of kernel using ld directly. This is actually one of very few cases where using ld directly is appropriate.
However, the command line arguments you give to ld assume that you are using GNU-ld (you may have copied them from a Linux tutorial), but you are not using GNU-ld, you are using MacOS native linker, which doesn't understand these arguments.
Can anybody help me with this?
Please ask a separate question, along the lines of "I am trying to build XXX on MacOS, following tutorial YYY, and don't understand how to adjust this Linux command to Mac OS".
Note that it may not be possible to build XXX on MacOS at all. In particular, the ld manpage does not mention ELF as possible output, so if your "build XXX" goal includes building an ELF kernel, you'll likely need to build a cross-linker (a GNU-ld linker which runs on Mac OS (i.e. hosted on Mac OS), but produces code for ELF target.
I'd like to specify GCC's search directory for the startfile and
endfile: crt1.o, crti.o and crtn.o. Passing -B on the command line to
the GCC driver works, but is inconvenient. How do I modify the specs
file (lib/gcc/x86_64-unknown-linux-gnu/4.9.2/specs) to specify the search path for startfile?
I tried adding the -B option to the startfile spec and got the error:
ld: unrecognized option '-B/gsc/btl/linuxbrew/lib'
I then tried adding the -B option to the cc1 spec and got the error:
cc1: error: command line option '-B/gsc/btl/linuxbrew/lib' is valid
for the driver but not for C
If it's not possible to do this via the specs file, is there an environment variable or a configure option to GCC that accomplishes the same goal?
I've installed a recent version of glibc in my home directory. Everything's working great. I've modified the specs file to link against the new version of glibc, but it's still linking against the old system version in /usr of startfile and endfile.
Here's a the unanswered question on the gcc-help mailing list. Here's a related Linuxbrew bug, gfortran is broken with stand alone Linuxbrew, and a proposed fix, gcc, binutils: link to Cellar instead of system libs.
Thanks,
Shaun
You can use an absolute path in the *startfile: and *endfile: sections in the specs file, instead of the default relative paths. This will override GCC's choice of the default location.
As per https://wiki.debian.org/Multiarch/LibraryPathOverview, gcc will look for startup files such as crt1.o in $(sysroot)/lib, so you can specify the --sysroot option when running gcc, or compile gcc with --with-sysroot.
Suppose I have a third party library called somelib.a on a Mac running Mountain Lion with Xcode 4.4 installed. I want to get a dynamic library out of it called somelib.dylib. An appropriate Linux command would be:
g++ -fpic -shared -Wl,-whole-archive somelib.a -Wl,-no-whole-archive -o somelib.so
where -whole-archive and -no-whole-archive are passed to the linker.
When I do the equivalent for Mac:
g++ -fpic -shared -Wl,-whole-archive somelib.a -Wl,-no-whole-archive -o somelib.dylib
ld fails with an error:
ld: unknown option: -whole-archive
It seems that the ld on OSX is different from GNU ld. How do I have to modify above command so I will get the desired result?
Thank you in advance!
I found out the solution to my problem:
g++ -fpic -shared -Wl,-force_load somelib.a -o somelib.dylib
The required argument is -force_load:
Which needs to be followed by a single library you wanna ensure gets loaded.
I mean, it needs to be repeated for each library (unlike -noall_load approach, which wrapped them).
For example, -Wl,-force_load libYetAnotherFile.a (where -Wl, part is only required because we don't pass parameter directly to linker).
Note that Old answer (before edit) was using -noall_load instead, but nowadays that causes a linker error (as -noall_load has been removed, was obsolete previously).
Note: A link for the documentation of the OSX ld linker.
http://www.unix.com/man-page/osx/1/ld/
I know it is late to give an answer for this, but I do not have enough reputation to make a comment on #hanslovsky answer.
However, it helps me a lot to have the docs of the options too.
It helps what the options do exactly, and that other options the ld linker also has.
So I just wanted to share with others who finds linking an issue.
UPDATE:
After the comment from #GhostCat I have decided to expand my answer.
The docs for -all_load is:
-all_load
Loads all members of static archive libraries.
So it loads for all static libraries that you note.
If you want something similar to --whole-archive and --no-whole-archive, then you need to use -force_load and -noall_load.
-force_load "path_to_archive"
Loads all members of the specified static archive library. Note: -
all_load forces all members of all archives to be loaded.
This option allows you to target a specific archive.
-noall_load
This is the default. This option is obsolete.
Then you can define which libraries to fully load with -force_load and then later turn it off again with -noall_load.
According to the ld manual, -noall_load is the default and is ignored. (If you use it, you get an error message: ld: warning: option -noall_load is obsolete and being ignored)
Apparently the way to get -all_load to apply to only one library is as follows:
-Wl,-force_load,somelib.a