I made a custom bash script for assembling, compiling, and linking the kernel but when it gets to the line for linking i run into an error (see below). Im running this on OSX, newest build so im not sure why. Any suggestions?
ld: unknown option: -T
My script:
echo Now assembling, compiling, and linking your kernel:
nasm -f aout -o start.o start.asm
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno- builtin -I./include -c -o main.o main.c
ld -T link.ld -o kernel.bin start.o
echo Done!
Before you try to create your own build scripts, have you managed to get the OSX kernel to build with its own scripts? This site by one of Apple's kernel engineers tells you how it's done.
Related
During installation of pintos, I had to run make.
Following is the Makefile.
all: setitimer-helper squish-pty squish-unix
CC = gcc
CFLAGS = -Wall -W
LDFLAGS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
In one computer it executed correctly. (output for the command is given below)
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
gcc -lm setitimer-helper.o -o setitimer-helper
gcc -Wall -W -c -o squish-pty.o squish-pty.c
gcc -lm squish-pty.o -o squish-pty
gcc -Wall -W -c -o squish-unix.o squish-unix.c
gcc -lm squish-unix.o -o squish-unix
but in other computer I got the following error
gcc -lm setitimer-helper.o -o setitimer-helper
setitimer-helper.o: In function `main':
setitimer-helper.c:(.text+0xc9): undefined reference to `floor'
collect2: error: ld returned 1 exit status
<builtin>: recipe for target 'setitimer-helper' failed
make: *** [setitimer-helper] Error 1
If looked at first line of outputs of both make commands
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
and
gcc -lm setitimer-helper.o -o setitimer-helper
They are different.
Why make is executing different commands for the same Makefile? and What should I do to remove error?
In the first computer, the setitimer-helper.o file either doesn't exist or the setitimer-helper.c file is newer, so make needs to rebuild it. Thus it runs the compiler, then afterwards it performs the link operation:
gcc -Wall -W -c -o setitimer-helper.o setitimer-helper.c
gcc -lm setitimer-helper.o -o setitimer-helper
On the second computer, the setitimer-helper.o file already exists and is newer than the setitimer-helper.c file, so the compile command was not needed and the second computer proceeded directly to the link line:
gcc -lm setitimer-helper.o -o setitimer-helper
The real question is why you got the linker error on the second computer.
The answer to that is that the -lm flag needs to come on the linker line after the object files. This happens because you added -lm to the LDFLAGS variable which is not the right one: that should contain options that tell the linker where to look for files, etc. (for example, the -L option).
Libraries should be added to the LDLIBS variable, not LDFLAGS. Change your makefile to this:
all: setitimer-helper squish-pty squish-unix
CC = gcc
CFLAGS = -Wall -W
LDLIBS = -lm
setitimer-helper: setitimer-helper.o
squish-pty: squish-pty.o
squish-unix: squish-unix.o
clean:
rm -f *.o setitimer-helper squish-pty squish-unix
Your link line will then look like:
gcc setitimer-helper.o -o setitimer-helper -lm
and should work properly.
I'm trying to compile a c++ program and I am having some issues. In particular, when I use x86_64-w64-mingw32-gcc as my compiler, it complains half way through my compilation saying "tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized".
Here is my makefile (not mine, I'm trying to adapt this makefile to a cygwin environment) https://pastebin.com/vgnVYJUL
Here is the console output when I run make:
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver.cpp.o src/libfastms/solver/solver.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_base.cpp.o src/libfastms/solver/solver_base.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/solver/solver_host.cpp.o src/libfastms/solver/solver_host.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/has_cuda.cpp.o src/libfastms/util/has_cuda.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
x86_64-w64-mingw32-gcc -c -o tmp/src/libfastms/util/image_mat.cpp.o src/libfastms/util/image_mat.cpp -Wall -O3 -m64 -Isrc/libfastms -DDISABLE_OPENMP -DDISABLE_OPENCV -DDISABLE_CUDA
ld -r -o tmp/src/libfastms/libfastms.o tmp/src/libfastms/solver/solver.cpp.o tmp/src/libfastms/solver/solver_base.cpp.o tmp/src/libfastms/solver/solver_host.cpp.o tmp/src/libfastms/util/has_cuda.cpp.o tmp/src/libfastms/util/image_mat.cpp.o
tmp/src/libfastms/solver/solver.cpp.o: file not recognized: File format not recognized
Makefile:167: recipe for target 'tmp/src/libfastms/libfastms.o' failed
make: *** [tmp/src/libfastms/libfastms.o] Error 1
Some other notes:
I don't have this problem when I compile with g++ (only seems to be minGW)
A common solution to this problem is to clean the directory of residual object files. This does not work.
Another common reason for this is trying to compile .h files. Obviously I am not doing this.
Thanks in advance.
You are compiling your object files with a 64-bit compiler driver, w64-mingw32-gcc,
and with -m64 you are explicitly directing it to generate 64-bit code (unnecessarily,
as that is its default). But you are linking with a 32-bit linker that does not
understand 64-bit object files.
This is happening because in your makefile you are, unusually, invoking ld
explicitly for your incremental solver linkage:
COMMAND_LINK_SOLVER=ld -r -o $# $^
rather than delegating linkage to your compiler driver in the usual way, and
a 32-bit ld from a different toolchain is being found in your PATH before
the 64-bit one belonging to your mingw-w64 toolchain.
To avoid this, invoke the linker via the compiler driver as normal, which for your
solver linkage means:
COMMAND_LINK_SOLVER=$(GXX) -Wl,-r -o $# $^
You can depend on w64-mingw32-gcc to invoke the ld that was installed with it.
There is no need to correct your main linkage as it is already done the right way.
I compile with the following command:
gcc -Wall -march=native -O3 -ffast-math -I/usr/local/include -I/usr/local/include -o waon main.o notes.o midi.o analyse.o fft.o hc.o snd.o -L/usr/local/lib -L/usr/local/lib -lfftw3 -L/usr/local/lib -lsndfile -lm
I now would like to compile with Emscripten. How do I convert the above gcc command into an emcc command?
The command you have described in the question is linking rather than compiling. However in general you should just be able to replace gcc with emcc and it will do the right thing. In this case you will need to replace not only this linking command but also the commands used to compile the sources to the .o files.
It would probably be a good idea to take out the -march option.
It looks like your project is using libsndfile and FFTW. You will probably need to compile these libraries yourself using emscripten. Both of them are using autotools so with a bit of luck you can compile them with emscripten simply by adding the following parameters when you run the configure script:
./configure --prefix=$HOME/emscripten-libs CC=emcc
make && make install
Then when you link your program you can specify -L$HOME/emscripten-libs/lib instead of -L/usr/local/lib.
Make research about emsdk download&setup on your computer.
Download emsdk instruction
Next interest link is :
emcc or em++ instruction
https://emscripten.org/docs/tools_reference/emcc.html
When you setup emcc in command line you can see this project (i make emcc final look based on python script runner.py etc.):
c-cpp-to-javascript
Basic and useful example's :
Pretty analog with gcc :
Args:
-lGL for openGL
-s TOTAL_MEMORY=512MB --memory-init-file 1 Memory staff
--preload-file folderWithImages/--use-preload-plugins If you use assets
-I forInclude/someheader.h
-L libraryFolder/someLib.lib
-std=c11
Simple run:
./emcc -O2 a.cpp -o a.js
or
./emcc -O2 a.cpp -o a.html
Links:
./emcc -O2 a.cpp -o a.bc
./emcc -O2 b.cpp -o b.bc
./emcc -O2 a.bc b.bc -o project.js
Or :
to get JS
emcc -s WASM=1 myAdds.a myLib.a source1.c source2.cpp -o build.js
to get html
emcc -s WASM=1 myAdds.a myLib.a source1.c source2.cpp -o build.html
Link together the bitcode files:
emcc project.bc libstuff.bc -o allproject.bc
Compile the combined bitcode to HTML
emcc allproject.bc -o final.html
Important note :
You can't take an existing .a library and convert it. You must build lib with emcc also.
I'm trying to create a shared library with my gcc. It's a gcc for vxworks (thats probably the problem...).
I use the gcc as following:
./gcc -shared -B/path/to/gnutools/bin -o test.so test.c
Result:
/path/to/ld: -r and -shared may not be used together
collect2: ld returned 1 exit status
If I try the same with the linux gcc, there's no problem. So i guess the gcc for VxWorks automatically passes the -r (or -i, which is the same and results in the same) flag to the linker. Is there a way to suppress this?
Greetz
marty
PS: making it static is not really an alternative...
Try compile object file separately with -fPIC and then link:
gcc -Wall -fPIC -c -o test.o test.c
gcc -Wall -shared -o test.so test.o
Another suggestion is to use libtool (at least to figure out the correct flags).
A workaround may be to go directly with ld:
ld -shared -o test.so test.o -lc
I'm trying to compile a program using a third party library, Omnet++ in my case. Apparently "make" does not find a library, but the path it uses is correct as you can see (in the sense that I can see the library under omnet++ source tree)
pv135168:basic Bob$ opp_makemake
Creating Makefile in /Users/Bob/Code/network_sim/basic... Makefile created, running "make depend" to add dependencies... opp_makedep -Y --objdirtree -I. -f Makefile -P\$O/ -- ./*.cc
pv135168:basic Bob$ make
g++ -c -g -Wall
-fno-stack-protector -m32 -DHAVE_PCAP -DXMLPARSER=libxml
-DWITH_PARSIM -DWITH_NETBUILDER -I.
-I/Users/Bob/Code/omnetpp-4.1/include -o out/gcc-debug//txc1.o txc1.cc g++ -m32 -Wl,-rpath,/Users/Bob/Code/omnetpp-4.1/lib -Wl,-rpath,. -o out/gcc-debug//basic out/gcc-debug//txc1.o -Wl,-all_load
-L"/Users/Bob/Code/omnetpp-4.1/lib/gcc"
-L"/Users/Bob/Code/omnetpp-4.1/lib" -u _tkenv_lib -lopptkenvd
-loppenvird -lopplayoutd -u _cmdenv_lib -loppcmdenvd -loppenvird
-loppsimd -lstdc++
ld: library not found for -lopptkenvd
collect2: ld returned 1 exit status make: *** [out/gcc-debug//basic]
Error 1 pv135168:basic Bob$
It's looking in the following directories for a file called libopptkenvd.dylib or libopptkenvd.a:
/Users/Bob/Code/omnetpp-4.1/lib/gcc
/Users/Bob/Code/omnetpp-4.1/lib
Is that file in one of those directories (or in the standard directories like /usr/lib)? I don't see an indication of that in your output.