My base assembler file foidlrt.asm started getting a bit too large so I broke it up into two. Here is the entirety of the second file folder_stdio.asm:
; foidl_stdio.asm
%include "foidlstnd.inc"
section .text
DEFAULT REL
global foidl_fclose ; Raw file close
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; foidl_close
; Raw file close
; REGISTERS (1):
; RDI file handle
; CALLS:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
foidl_fclose:
mov rax,SYSCALL_FILE_CLOSE ; 0x2000006
syscall
ret
However, now when I build I am now getting this error from make despite the global declaration in the new file:
nasm src/foidlrt.asm -f macho64 --prefix _ -g -O0 -Iincludes/ -o asmobjs/foildrt.o
nasm src/foidlrt.asm -f macho64 --prefix _ -g -O0 -Iincludes/ -o asmobjs/foidl_stdio.o
libtool -static -s -o libs/libfoidlrt.a asmobjs/foildrt.o asmobjs/foidl_stdio.o
gcc src/testlink.c -L libs -l foidlrt -Wall -g -L. -Wl,-pie -I. -o bin/testlink
Undefined symbols for architecture x86_64:
"_foidl_fclose", referenced from:
_main in testlink-4b5ad3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Version information:
XCode - 7.2.1 (7C1002)
nasm - NASM version 2.12 compiled on Feb 28 2016
gcc - Apple LLVM version 7.0.2 (clang-700.1.81)
RESOLVED
Error was all mine, makefile rule was bad. Working as expected now.
Related
After some struggle, I must admit I need some external help on this linker issue. AIX will kill me otherwise.
I am striving to migrate our build from GCC 4.8.5 to GCC 6.3.0 under AIX 7.1:
> uname -a
AIX wreckmach 1 7 00F63B074C00
> oslevel
7.1.0.0
Now, all the compilation phase is going well, but at link stage things starts going messy. My compilation line is like the following (I removed includes directories and some internal defines):
g++ -std=c++11 -Wno-deprecated -g -pthread -shared -maix64 -gdwarf -g3 -O3 -fPIC -fPIC -I./some/includes -D_REENTRANT=1 -DAIX53=1 -DAIX=1 -DNDEBUG=1 -DSVR4=1 -D__VACPP_MULTI__=1 -DRS6000=1 myCppFile.cpp -c -o /home/me/migration/build.AIX71_GCC_60300_64/myCppFile.cpp.1.o
And my link line is
g++ -g -ggdb3 -pthread -maix64 -Wl,-brtl -Wl,-bhalt:5 -Wl,-bnodelcsect -Wl,-brtl,-bexpfull -shared /home/me/migration/build.AIX71_GCC_60300_64/myCppFile.cpp.1.o /home/me/migration/build.AIX71_GCC_60300_64/myOtherCppFile.cpp.1.o -o /home/me/migration/build.AIX71_GCC_60300_64/libtest.so -L/BUILD/SOFT/compilers/AIX71/GCC/60300/lib64 -lgcc_s -lstdc++ -lpthread
This gives me the following output:
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: error: ld returned 8 exit status
By adding the -bnoquiet options, I got :
(ld): save SRE .
SAVE: Section sizes = 69976+5192+280 (0x11158+0x1448+0x118 hex)
SAVE: Size of TOC: 1352 (0x548 hex)
ld: 0711-310 ERROR: Relocation entries from the .text section have been
written to the .loader section. The following csects are in error:
CSECT or (Symbol in CSECT) Inpndx Address TY CL Source-File(Object-File)
Symbols referenced with .loader section RLDs: TY CL Inpndx Name
--------------------------------------------- -- -- ------------------------
<_myCppFile.ro_> [260] 00004080 SD RO ../src/myCppFile.cpp(./build.AIX71_GCC_60300_64/myCppFile.cpp.1.o)
ER PR [140] __gcc_unwind_dbase
SD RW [264] <_myCppFile.rw_>
<_myOtherCppFile.ro_> [107] 00002240 SD RO ../src/myOtherCppFile.cpp(./build.AIX71_GCC_60300_64/myOtherCppFile.cpp.1.o)
SD RW [111] <_myOtherCppFile.rw_>
ER PR [56] __gcc_unwind_dbase
SAVE: The return code is 4.
(ld): rc
RC: Highest return code was 4.
A quick look at libgcc_s/libstdc++ shows that this symbol is defined and exported:
> nm -X64 /BUILD/SOFT/compilers/AIX71/GCC/60300/lib64/libgcc_s.a | grep __gcc_unwind
__gcc_unwind_dbase D 536871816
__gcc_unwind_dbase d 536871816 4
__gcc_unwind_dbase d 536876288 8
> nm -X64 /BUILD/SOFT/compilers/AIX71/GCC/60300/lib64/libstdc++.a | grep __gcc_unwind
__gcc_unwind_dbase D 536871608
__gcc_unwind_dbase d 536871608 4
__gcc_unwind_dbase d 537025144 8
What am I missing and doing wrong?
I precise that the result is the same regardless of which ld I use (system one --prefered-- or gnu binutils one)
EDIT When I create a dummy library and link an executable on it, everything went fine. The whole stuff is using the same options, except the external libraries used in the above quoted project. I am now completely stuck... T_T
I want to link a DLL using a couple of other DLLs but am having trouble getting them to properly resolve:
$ g++ -o libsuba.dylib -dynamiclib -Wl,-install_name,#rpath/libsuba.dylib suba.cpp
$ g++ -o liba.dylib -dynamiclib -Wl,-install_name,#rpath/liba.dylib -Wl,-reexport_library,libsuba.dylib a.cpp
The above gives me the two libraries, liba.dylib and libsuba.dylib.
$ otool -l liba.dylib
...
Load command 10
cmd LC_REEXPORT_DYLIB
cmdsize 48
name #rpath/libsuba.dylib (offset 24)
time stamp 2 Wed Dec 31 18:00:02 1969
current version 0.0.0
compatibility version 0.0.0
...
In another directory, I want to now link against liba.dylib:
$ cd build
$ c++ -o b b.cpp ../liba.dylib -Wl,-rpath,..
ld: file not found: #rpath/libsuba.dylib for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
However, this works:
$ c++ -o b b.cpp ../liba.dylib -L..
Can someone explain why the explicit linker rpath option doesn't replace the #rpath macro and allow the reexported library to be located?
I got a problem with link objective files on a Mac OS X. Tracing back the problem is,
here is my C hello world program
#include <stdio.h>
int main(){
printf("Hello, world!\n");
return 0;
}
//Compile with gcc (clang LLVM compiler on mac)
$ gcc -c hello.c
The output file is hello.o
link with gcc and run the executable is
$ gcc hello.o -o hello
$ ./hello
Now, I have to use the mac linker program ld or Ld to link the the objective files instead of gcc. In this case, what arguments should I pass into the ld program in order to get the program run? A simple pass in the object file name, i.e.
$ ld hello.o
resulting in
ld: warning: -macosx_version_min not specified, assuming 10.6
Undefined symbols for architecture x86_64:
"_printf", referenced from:
_main in hello.o
"start", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for inferred architecture x86_64
So what other files that i need to include to link or architecture information that I need to specify? Thanks.
For a reference, my complete linker options are
ld -demangle -dynamic -arch x86_64
-macosx_version_min 10.9.0
-o hello
-lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/lib/darwin/libclang_rt.osx.a
Okay, I had this question before too. Yes, the reason for the linker errors is because you need to feed it all the magic arguments that gcc does. And the easy way to discover those is to invoke the -v option on gcc to reveal all the commands executed in the compilation stages. In your case, run:
gcc hello.o -o hello -v
...the output of which, on my system, ends with the line:
/usr/libexec/gcc/i686-apple-darwin9/4.2.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.8 -weak_reference_mismatches non-weak -o test -lcrt1.10.5.o -L/usr/lib/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1/../../../i686-apple-darwin9/4.2.1 -L/usr/lib/gcc/i686-apple-darwin9/4.2.1/../../.. test.o -lgcc_s.10.5 -lgcc -lSystem
I don't know what the collect2 program is, but if you feed all those arguments to ld it should work just the same (at least it does on my system).
So, i write some instruction on asm, and compile them.
nasm -f macho test.asm
Now, nasm generate obj file, test.o
gcc test.o
Returned next error:
ld: warning: ignoring file test.o, file was built for unsupported file
format which is not the architecture being linked (x86_64)
Undefined
symbols for architecture x86_64: "_main", referenced from:
start in crt1.10.6.o ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status
in gcc line, i used -arch i386 (x86_64), returned same error.
Can anybody help? :)
These commands work for me (OS X 10.12 x64):
nasm -f macho test.asm -DDARWIN
ld -o test test.o -arch i386 -lc -no_pie -macosx_version_min 10.12 -lSystem
macho is a 32 bit format.
Try to use macho64 instead of macho. Complete line:
nasm -f macho64 test.asm
Try to update your nasm version and use the following command:
/usr/local/bin/nasm -f macho64 ${file}
ld -o ${file_path}/${file_base_name} -e _main ${file_path}/${file_base_name}.o
${file_path}/${file_base_name}
i have some problems with linking nasm program for macos:
GLOBAL _start
SEGMENT .text
_start:
mov ax, 5
mov bx, ax
mov [a], ebx
SEGMENT .data
a DW 0
t2 DW 0
fry$ nasm -f elf test.asm
fry$ ld -o test test.o -arch i386
ld: warning: in test.o, file was built for unsupported file format which is not the architecture being linked (i386)
ld: could not find entry point "start" (perhaps missing crt1.
fry$ nasm -f macho test.asm
fry$ ld -o test test.o -arch i386
ld: could not find entry point "start" (perhaps missing crt1.o)
can anyone help me?
The Mac OS X linker can't link ELF objects. It works only with the Mach-O executable format. Unless you want to figure out how to translate the object files, you'll probably be better off writing code that works with the Mac OS X assembler.
Edit: As #Fry mentions in the comment below, you can make nasm put out Mach-O objects. In that case, the problem is simple - take the _ off of _start in both places in your source file. The result links fine.
nasm -f macho test.asm
ld -e _start -o test test.o
For people who need to stick with the elf format and develop on a mac, you need a cross compiler...
http://crossgcc.rts-software.org/doku.php?id=compiling_for_linux
Then you can proceed with something similar to this...
/usr/local/gcc-4.8.1-for-linux32/bin/i586-pc-linux-ld -m elf_i386 -T link.ld -o kernel kasm.o kc.o