I am currently following the Bare Bones tutorial from OSDev and i have set up everything and compiled the kernel and bootloader into object files, and i have the .ld file. However, when i try to link the files and produce it into a bin using i686-elf-gcc -T linker.ld -o myos.bin -ffreestanding -O2 -nostdlib boot.o kernel.o -lgcc, i get this error:
.../i686/bin/../lib/gcc/i686-elf/4.8.2/../../../../i686-elf/bin/ld.exe: cannot open linker script file linker.ld
collect2.exe: error: ld returned 1 exit status
I am using GCC and using the compiled version of i686-elf-gcc which includes many more compilers and i have added 4 dlls as it was missing (also not related to linker), but i installed MinGW and added them. I am on Windows 10 x64. Many of the solutions or workarounds i find just brings up more errors or does absolutely nothing to the errors (-T doesn't do anything, -noixemul is not a parameter.). I removed multiboot content since i am gonna use a sector-long bootloader which loads the object files.
If i'm not mistaken, your problem is really, really, really simple:
You don't have access to linker.ld. Try running as superuser or changing the permissions.
If this doesn't solve it, you have an actual problem. Try not using the -T flag.
EDIT: Dear god, I didn't expect this to be right. Thanks!
Related
I'm going through the tutorial on making an OS on http://wiki.osdev.org/Bare_Bones. When I try to link boot.o and kernel.o using this command: i686-elf-gcc -T linker.ld -o myos.bin -ffreestanding -O2 -nostdlib boot.o kernel.o -lgcc , I just get this error:
collect2: fatal error: cannot find 'ld'
compilation terminated.
I just installed fresh Ubuntu 15.10 that with gcc-5.2.1 and binutils-2.25.1 .
I have searched the internet for answers but nothing helped.
I also got once the same error during a pentest while I was trying to compile my exploit on the victim server.
In my case, the directory where the "ld" program was located had not been defined in the PATH environment variable, so I simply added it.
eg. export PATH=$PATH:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin
I had this error while hacking a remote machine and trying to use gcc to compile an exploit on the victim machine.
I simply copied the program ld to /tmp/, the working directory where i was compiling my exploit exploit.c by running
cp /usr/bin/ld /tmp/ld
followed by the original gcc compile command and the compile worked.
I searched a lot to fix this issue and nothing worked but lastly i uninstalled MinGw and reinstalled it then did edited the environment variables again and then uninstalled and reinstalled vs code extensions then it worked.
I'm trying to use liboauth with a C program, using gcc as my compiler, and no matter what I've tried I keep getting the error "ld: library not found for -loauth" and "clang: error: linker command failed with exit code 1".
I'm including the header via "#include <oauth.h>", and my most-recent call to gcc looked like this:
gcc -Wall -lcurl -loauth -I /usr/local/include -v -o api api.c
Now, oauth.h does exist in /usr/local/include, and there are a handful of liboauth files (including liboauth.a) located in /usr/local/bin, which I'm assuming were placed there when I ran the install. I will admit that I'm not very familiar with gcc and compiling non-trivial C programs, but I was able to get libcurl working on a fresh download in just a few minutes. I just can't figure out what's going on with liboauth.
Thanks in advance
If you are sure liboauth's located in /usr/local/bin use
gcc -Wall -L/usr/local/bin -I /usr/local/include -v -o api api.c -lcurl -loauth
It'd also be better to place libraries in the end of the command as there is some important stuff with them (they may depend on each other, etc).
By the way, it's pretty strange your libraries are in /usr/local/bin as libraries are almost always stored in some path like /usr/*/lib.
I'm currently trying to compile Clang/LLVM for a bare metal aarch64 target. Compiling Clang was straightforward - in fact I have compiled to target multiple architectures including arm and aarch64. For the backend I'm using binutils. Since binutils can only target one architecture I've built both aarch64 and arm versions of this. Again building seemed to be straightforward. I built binutils for aarch64 using:
mkdir build
cd build
../configure --target=aarch64-none-elf
make
from an unpacked source package of binutils 2.24.
The problem I'm having is that I can't get my custom build of ld to handle archive files properly. It seems to find and open archive files without a problem but fails to search it for undefined symbols when compiling the final binary. Here's some more concrete details via an example:
Create a simple main.s file by compiling:
int foo();
int main() { return foo(); }
with Clang and using --target=aarch64 -S, i.e. to emit an architecture specific assembly file.
Do the same to create foo.s by compiling:
int foo() { return 0; }
Assemble both .s files to .o files using custom gas build from binutils.
Create an archive libfoo.a by running custom ar and ranlib builds from binutils using ar cr foo.a foo.s and ranlib libfoo.a.
Try to link the two files together using ld -L. -lfoo -o main.elf main.o.
The output shows an undefined reference to foo.
bar.cpp:(.text+0x14): undefined reference to `foo()'
I can run readelf on foo.a and it seems perfectly well formed. In particular I can see the public symbol for foo. If I run ld with --verbose then I see
attempt to open ./libfoo.a succeeded
but no indication that it's found any symbols.
If I link directly with the object files, i.e. using ld -o main.elf foo.o main.o then I get a well formed elf file. Furthermore, if I extract foo.o back out of libfoo.a then I can also link succesfully with the extracted foo.o.
Does anyone have any ideas why this might be happening? I'm pretty sure my clang build is okay as the emitted assembly files effectively decouple the problem from clang. I'd guess also that the assembled .o files are fine. So this only leaves ar/ranlib or ld as the culprit.
To try to eliminate ar/ranlib as the culprits I rebuilt binutils for arm (same steps but using --target=arm-none-eabi). If I integrate the built ar/ranlib binaries into a known good arm-eabi-none GCC toolchain then they seem to work correctly. My suspicions thus point to ld at the moment. Note that I get the same problem with the main/foo example as above if I use my Clang build with the arm build of binutils.
I also tried integrating the arm version of ld into the existing known good GCC toolchain, but got:
this linker was not configured to use sysroots
Need to figure that out. That's still a bit cryptic for me right now. It prevents me from sanity checking the arm ld build.
It might well be that I'm doing something obviously wrong, but right now I don't see it.
Notes:
I had to hack the make script for binutils to add a couple of -Wno-xxx flags. I need to do this the "correct" way, but I don't think this hack should affect the output.
I'm building/hosting all tools on OSX 10.9.4 64-bit.
UPDATE:
The error about sysroots is simple. The pre-existing toolchain was configured with flags:
--with-prefix $SOME_INSTALL_DIR
--with-sysroot $SOME_INSTALL_DIR/arm-none-eabi
If I rebuild with these then I can slot in my ld version without a problem and it works. I got excited thinking that this might have been my mistake. Previously I wasn't running make install as I didn't really care about installing at this stage. I thought perhaps my new build of ld was referencing OSX system libs/exes somehow (although I'm not sure exactly what it could reference, other than perhaps ar, i.e. if it runs ar to handle archives). However I still have the same problem with both the arm and arrach64 versions of binutils even when configured like this.
Looks like I was dramatically overthinking the problem and also missing something I'd never quite realised about ld. The issue was with the line:
ld -L. -lfoo -o main.elf main.o
I hadn't realise that ld is sensitive to object file/library ordering. The undefined reference to foo() was in main.o. I specified the library libfoo.a as input before main.o is parsed. This means that the linker doesn't bother searching libfoo.a for the symbol as it's already processed this library. main.o must be specified before, e.g.
ld -L. main.o -lfoo -o main.elf
Even wrapping -lfoo with --start-group ... --end-group doesn't fix this.
I'm still feeling somewhat surprised by this. And I've yet to convince myself it's a good feature of ld. Seems like the only use case I can think of right now is to sneakily allow duplicate symbols.
Time for a cup of tea!
I was searching for a way to create mocking objects with c-code until I stumbled upon cmockery.
For me it seems to be the best mocking software available since it doesn't have a lot of dependencies.
I'm working in ubuntu and downloaded the tarball cmockery from https://code.google.com/p/cmockery/downloads/list
I ran the ./configure, make and make install.
I am able to execute the given examples but I just can't figure out how to get it working on my own projects. I had a look at the configure and makefile to try and find out how they did it, but that was no success. I think it's the linking that's causing my problems.
Files of cmockery can be find at:
/usr/local/include/google/cmockery.h
/usr/local/lib/libcmockery.la
/usr/local/lib/libcmockery.a
/usr/local/lib/libcmockery.so.0.0.0
/usr/local/lib/libcmockery.so.0
/usr/local/lib/libcmockery.so
I tried copying the example files calculator.c and calculater_test.c to a separate directory and compile them there.
This is what I did:
gcc -c -o calculator.o calculator.c
gcc -c -o calculator_test.o calculator_test.c -I /usr/local/include/google/
gcc -o run *.o -L /usr/local/lib/
At the last step I got a lot of undefined references to all functions specific to cmockery and the error:
collect2: error: ld returned 1 exit status
I guess I'm messing things up with the linker but I can't find anywhere how it should be done correctly.
You are missing -lcmockery:
gcc -o run *.o -L /usr/local/lib/ -lcmockery
I am trying to install the driver for a serial device, and when I run the installation executable I get this error:
cc -DLINUX -c -DMODVERSIONS -DMODULE -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -m64 -mcmodel=kernel -I/usr/src/linux-3.8.0-27-generic/include -I/usr/src/linux-2.4/include -I/usr/src/linux/include -D__SMP__ npreal2.c
npreal2.c:40:31: **fatal error: linux/modversions.h: No such file or directory**
compilation terminated.
I don't find any solutions to this after searching the forums. I noticed that there is a modversions.h in the /usr/src/linux-3.8.0-27-generic/include/config , but not in the linux folder.
Please help!
Try passing -I /usr/src/linux-3.8.0-27-generic/include/config as an argument to make?
or
Check if the header is a part of a certain package and update the package.
You can compile modversions on your system by navigating to the linux directory (usually usr/src/linux). Inside the linux source directory, there should be a file called Rules.make. Inside this make file are build commands for making modversions.h. You can make it by running:
make update-modverfile
Now, while this will make the modversions.h library, if you compile it with a newer compiler than the libraries that this file relies on, many times you will get an error when trying to run a program that uses this header. This then turns into a nightmare.
Another method, I tried it successfully with Xubuntu 13.10:
Open /etc/default/grub
Add this Line and save it.
GRUB_CMDLINE_LINUX="CONFIG_MODVERSIONS=true"
reboot
(no, sudo update-grub,ok)
open a terminal window, enjoy.
locate modversions.h
(Please don't forget modversion'S')