I've started writing my very own kernel and am developing on Windows 10.
I am using the following tools:
gcc 8.1.0 elf x86_64 for compiling my C code, and for linking.
I am using this Windows package.
nasm 2.14.02 for compiling my assembly code.
I am using the following command to build my freestanding kernel code:
gcc -c -m64 common/src/kernel.c -o common/build/kernel.o -std=gnu99 -ffreestanding -O2 -Wall -Wextra`
I am using the following command for compiling the root assembly code:
nasm -f elf64 targets/x86_64/src/main.asm -o targets/x86_64/build/main.o
Finally I link the object files together:
gcc -o dist/x86_64/main.bin -ffreestanding -O2 targets/x86_64/build/main.o common/build/kernel.o -lgcc
I haven't a clue why, but the following error is stopping the linking process from working:
... undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status
This doesn't make sense to me because my compilation and linking is in freestanding mode and I am not attempting to use any windows APIs.
How do I fix this?
If it matters, here is my very simple code:
main.asm:
EXTERN kernel_main
call kernel_main
jmp $
; padding and magic number
times 510-($-$$) db 0
dw 0xaa55
kernel.c:
void kernel_main()
{
// empty
}
Edit: It looks like I might need the x86_64-elf-gcc compiler
Edit 2: I tried the x86_64-w64-mingw32-gcc compiler, same error occurs
I was missing the -nostdlib flag on the linker. This seems to have solved the problem.
Related
I'm trying to compile a program that I've been able to compile on several other Debian environments with no issues using the C11 <threads.h> library on a relatively fresh install of Debian Bullseye with "gcc (Debian 10.2.1-6) 10.2.1 20210110" installed
with the command
gcc -o <progname> -O3 -Wall -Wextra -std=c11 -lpthread <sourcefile>
and I'm getting a string of linker errors in the form of
undefined reference to 'mtx_unlock'
as well as mtx_lock mtx_init thrd_create etc.
But I'm not getting an error saying the threads.h file is absent. I tried removing the -lpthread argument from the compilation command but this changed nothing.
What is going wrong?
The correct command line parameter seems to be -pthread without the l.
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
Preamble: this question is not about Oracle, instead I'd like to understand the fundamental difference between gcc-4 and gcc-6 in the handling of Position Independent Code.
So I have decided to try an Oracle 12c installation on a Debian stretch.
During the link stage with gcc-6, error messages like the following are issued:
/usr/bin/ld: /opt/oracle/product/12.2.0/lib/libpls12.a(pci.o):
relocation R_X86_64_32S against `.rodata.str1.4' can not be used when making a shared object;
recompile with -fPIC.
However, if I switch the compiler to use gcc-4.9, all the linking is done without any problems.
Thus my 2 questions:
Is there a change in the defaults for -fPIC and -fPIE between gcc version 4 and 6? Most probably yes, version 6 seems to use the 2 options by default.
More important for me: does gcc, version 6 have an option to use the version 4 behavior for the generation of position independent code? (Or will I sooner or later no more be able to link against old libraries because gcc-4 is no more available?)
Most likely the gcc-6 linker creates position independent executables by default. The problem can be reproduced as follows and solved by adding the linker flag -no-pie:
UNIX # gcc-6 -g -Wall -fno-pic -c helloworld.c -o helloworld.o
UNIX # gcc-6 -g -Wall helloworld.o -o helloworld
/usr/bin/ld: helloworld.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
UNIX # gcc-6 -g -Wall -no-pie helloworld.o -o helloworld
Indeed, after adding -no-pie to the gcc options used by Oracle, linking works without any errors.
Solution from broeni works fine. Some additional steps I made to make it work:
During installation, I modified the default linker tool from oracle, editing the file
/opt/oracle/product/12.2.0/db1/bin/orald
In the first lines, I forced to use GCC linker, and add the -no-pie option:
#if [ -z "$BASH_VERSION" -o -n "$ORALD_USE_GCC" ] ; then
exec gcc -no-pie "$#"
exit 1
#fi
tags: oracle 12c debian stretch
I'm trying to compile a .s file containing the following code:
.text
.globl memcpy_armneon
memcpy_armneon:
pld [r1, #0xC0]
vldm r1!,{d0-d7}
vstm r0!,{d0-d7}
subs r2,r2,#0x40
bge memcpy_armneon
but XCode 4.5 complains:
"LLVM GCC 4.2 error No such instruction: 'pld [r1,'. Is there a way to compile this?
OK, it's psychic debugging time. I have Xcode 4.6 here, and it doesn't appear to even have an ARM version of LLVM GCC:
$ gcc -arch armv7 -c -o example.o example.s
llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/arm-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
That leads me to believe that you're handing this code to an Intel assembler. In fact, I get precisely that error wording for your file when doing just that:
$ gcc -c -o example.o example.s
example.s:5:no such instruction: `pld [r1,'
example.s:6:no such instruction: `vldm r1!,{d0-d7}'
example.s:7:no such instruction: `vstm r0!,{d0-d7}'
example.s:8:too many memory references for `sub'
example.s:9:no such instruction: `bge memcpy_armneon'
You might want to use clang so that you can actually use an ARM assembler:
clang -arch armv7 -c -o example.o example.s
I need compile a piece of C code to be called from matlab (mex compiling).
I am doing that on an intel mac and, since I am using Matlab's R2010a (7.10.0.499), I'd like to compile the C code into a version for 64-bits.
For whatever reason, just doing mex with the -arch=maci64 option did not seem to work...
As a way around, I am compiling the C code to a mexmaci64 file directly on the command line.
I used the gcc calls made by mex (with the -v option on) as a starting point.
I managed to compile the C code to an object file, but it looks like I am not compiling the C code to the correct architecture.
Does anyone know how to correct the gcc calls below so the C code gets compiled to 64-bits intel macs?
Details are listed below.
As always, any help greatly appreciated...
Keep thirsty, my friends. :p
G
DETAILS:
Here is how I did the compilation and linking:
gcc -c -I/Applications/MATLAB_R2010a.app/extern/include -DMATLAB_MEX_FILE -fno-common -no-cpp-precomp -fexceptions -D MACVERSION -DMX_COMPAT_32 -O3 -DNDEBUG "BoxQP.c"
gcc -O -bundle -Wl,-flat_namespace -undefined suppress -Wl,-exported_symbols_list,/Applications/MATLAB_R2010a.app/extern/lib/maci64/mexFunction.map -o "BoxQP.mexmaci64" BoxQP.o -L/Applications/MATLAB_R2010a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Here are the warnings I get:
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmx.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmex.dylib, file is not of required architecture
ld warning: in /Applications/MATLAB_R2010a.app/bin/maci64/libmat.dylib, file is not of required architecture
Ignoring the warnings and calling the BoxQP function from matlab results in the following error message:
??? Invalid MEX-file '/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64':
dlopen(/Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64, 1): no suitable image found.
Did find: /Users/gvrocha/Documents/academic/projects/splice/code/matlab/covsel/BoxQP.mexmaci64: mach-o, but wrong architecture.
PS: I tried changing the -DMX_COMPAT_32 flag to -DMX_COMPAT_64 but I do get the same warnings and same error...
PPS: I guess it may be relevant to mention that I am using Mac OS X 10.5.8 (the "tropical"/plain-vanilla Leopard, i.e., not the snow Leopard).
PPPS: The same happens with the yprime.c example provided by MATLAB