Getting undefined reference to “printf” error for assembly code despite using gcc linker
up vote
1
down vote
favorite
I am trying to follow the exercise in the book PC Assembly by Paul Carter. http://pacman128.github.io/pcasm/
I'm trying to run the program from 1.4 page 23 on Ubuntu 18. The files are all available on the github site above.
Since original code is for 32bit I compile using
nasm -f elf32
for first.asm and asm_io.asm to get the object files. I also compile driver.c
I use the linker from gcc and run
gcc -m32 -o first first.o asm_io.o driver.o
but it keeps giving me a bun of errors like
undefined reference to '_scanf'
undefined reference to '_printf'
(note _printf appears instead of printf because some conversion is done in the file asm_io.asm to maintain compatibility between windows and linux OS's)
I don't know why these errors are appearing. I also try running using linker directly
ld -m elf_i386 -e main -o first -first.o driver.o asm_io.o -I /lib/i386-linux-gnu/ld-linux.so.2
and many variations since it seems that its not linking with the C libraries.
Any help? Stuck on this for a while and couldn't find a solution on similar questions
linux assembly x86 linker nasm
add a comment |
up vote
1
down vote
favorite
I am trying to follow the exercise in the book PC Assembly by Paul Carter. http://pacman128.github.io/pcasm/
I'm trying to run the program from 1.4 page 23 on Ubuntu 18. The files are all available on the github site above.
Since original code is for 32bit I compile using
nasm -f elf32
for first.asm and asm_io.asm to get the object files. I also compile driver.c
I use the linker from gcc and run
gcc -m32 -o first first.o asm_io.o driver.o
but it keeps giving me a bun of errors like
undefined reference to '_scanf'
undefined reference to '_printf'
(note _printf appears instead of printf because some conversion is done in the file asm_io.asm to maintain compatibility between windows and linux OS's)
I don't know why these errors are appearing. I also try running using linker directly
ld -m elf_i386 -e main -o first -first.o driver.o asm_io.o -I /lib/i386-linux-gnu/ld-linux.so.2
and many variations since it seems that its not linking with the C libraries.
Any help? Stuck on this for a while and couldn't find a solution on similar questions
linux assembly x86 linker nasm
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am trying to follow the exercise in the book PC Assembly by Paul Carter. http://pacman128.github.io/pcasm/
I'm trying to run the program from 1.4 page 23 on Ubuntu 18. The files are all available on the github site above.
Since original code is for 32bit I compile using
nasm -f elf32
for first.asm and asm_io.asm to get the object files. I also compile driver.c
I use the linker from gcc and run
gcc -m32 -o first first.o asm_io.o driver.o
but it keeps giving me a bun of errors like
undefined reference to '_scanf'
undefined reference to '_printf'
(note _printf appears instead of printf because some conversion is done in the file asm_io.asm to maintain compatibility between windows and linux OS's)
I don't know why these errors are appearing. I also try running using linker directly
ld -m elf_i386 -e main -o first -first.o driver.o asm_io.o -I /lib/i386-linux-gnu/ld-linux.so.2
and many variations since it seems that its not linking with the C libraries.
Any help? Stuck on this for a while and couldn't find a solution on similar questions
linux assembly x86 linker nasm
I am trying to follow the exercise in the book PC Assembly by Paul Carter. http://pacman128.github.io/pcasm/
I'm trying to run the program from 1.4 page 23 on Ubuntu 18. The files are all available on the github site above.
Since original code is for 32bit I compile using
nasm -f elf32
for first.asm and asm_io.asm to get the object files. I also compile driver.c
I use the linker from gcc and run
gcc -m32 -o first first.o asm_io.o driver.o
but it keeps giving me a bun of errors like
undefined reference to '_scanf'
undefined reference to '_printf'
(note _printf appears instead of printf because some conversion is done in the file asm_io.asm to maintain compatibility between windows and linux OS's)
I don't know why these errors are appearing. I also try running using linker directly
ld -m elf_i386 -e main -o first -first.o driver.o asm_io.o -I /lib/i386-linux-gnu/ld-linux.so.2
and many variations since it seems that its not linking with the C libraries.
Any help? Stuck on this for a while and couldn't find a solution on similar questions
linux assembly x86 linker nasm
linux assembly x86 linker nasm
edited 2 days ago
Peter Cordes
114k16171294
114k16171294
asked 2 days ago
ackbar03
253
253
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
4
down vote
accepted
Linux doesn't prepend _
to names when mapping from C to asm symbol names in ELF object files1.
So call printf
, not _printf
, because there is no _printf
in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf
, Linux uses printf
.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out
file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf
and so on, but it requires you to manually define ELF_TYPE
by assembling with nasm -d ELF_TYPE
.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__
. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
1
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
@ackbar03: They could have used%ifidn __OUTPUT_FORMAT__, elf32
(and also check forelf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?
– Peter Cordes
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
Linux doesn't prepend _
to names when mapping from C to asm symbol names in ELF object files1.
So call printf
, not _printf
, because there is no _printf
in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf
, Linux uses printf
.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out
file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf
and so on, but it requires you to manually define ELF_TYPE
by assembling with nasm -d ELF_TYPE
.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__
. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
1
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
@ackbar03: They could have used%ifidn __OUTPUT_FORMAT__, elf32
(and also check forelf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?
– Peter Cordes
2 days ago
add a comment |
up vote
4
down vote
accepted
Linux doesn't prepend _
to names when mapping from C to asm symbol names in ELF object files1.
So call printf
, not _printf
, because there is no _printf
in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf
, Linux uses printf
.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out
file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf
and so on, but it requires you to manually define ELF_TYPE
by assembling with nasm -d ELF_TYPE
.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__
. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
1
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
@ackbar03: They could have used%ifidn __OUTPUT_FORMAT__, elf32
(and also check forelf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?
– Peter Cordes
2 days ago
add a comment |
up vote
4
down vote
accepted
up vote
4
down vote
accepted
Linux doesn't prepend _
to names when mapping from C to asm symbol names in ELF object files1.
So call printf
, not _printf
, because there is no _printf
in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf
, Linux uses printf
.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out
file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf
and so on, but it requires you to manually define ELF_TYPE
by assembling with nasm -d ELF_TYPE
.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__
. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
Linux doesn't prepend _
to names when mapping from C to asm symbol names in ELF object files1.
So call printf
, not _printf
, because there is no _printf
in libc.
Whatever "compatibility" code did that is doing it wrong. Only Windows and OS X use _printf
, Linux uses printf
.
So either you've misconfigured something or defined the wrong setting, or it requires updating / porting to Linux.
Footnote 1: In ancient history (like over 20 years ago), Linux with the a.out
file format did use leading underscores on symbol names.
Update: the library uses the NASM preprocessor to %define _scanf scanf
and so on, but it requires you to manually define ELF_TYPE
by assembling with nasm -d ELF_TYPE
.
They could have detected ELF32 or ELF64 output formats on their own, because NASM pre-defines __OUTPUT_FORMAT__
. Someone should submit a pull-request to make this detection automatic with code something like this:
%ifidn __OUTPUT_FORMAT__, elf32
%define ELF_TYPE 32
%elifidn __OUTPUT_FORMAT__, elf64
%define ELF_TYPE 64
%endif
%ifdef ELF_TYPE
...
%endif
edited 2 days ago
answered 2 days ago
Peter Cordes
114k16171294
114k16171294
1
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
@ackbar03: They could have used%ifidn __OUTPUT_FORMAT__, elf32
(and also check forelf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?
– Peter Cordes
2 days ago
add a comment |
1
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
@ackbar03: They could have used%ifidn __OUTPUT_FORMAT__, elf32
(and also check forelf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?
– Peter Cordes
2 days ago
1
1
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
I was just gonna point out that in the asm_io.asm file the author included (includes some functions used for debugging) it has a section %ifdef ELF_TYPE %define _scanf scanf %define _printf printf but then I took a closer look and in the comments it said to compile with nasm -f elf -d ELF_TYPE asm_io.asm and uh... yea that solved the problem lol, stupid me. So i guess thanks haha, and for the very prompt answer. I'll put this as the right answer
– ackbar03
2 days ago
@ackbar03: They could have used
%ifidn __OUTPUT_FORMAT__, elf32
(and also check for elf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?– Peter Cordes
2 days ago
@ackbar03: They could have used
%ifidn __OUTPUT_FORMAT__, elf32
(and also check for elf64
) to avoid you having to manually do anything on the NASM command line. Someone should send in a pull request. How to detect architecture in NASM at compile time to have one source code for both x64 and x86?– Peter Cordes
2 days ago
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53237752%2fgetting-undefined-reference-to-printf-error-for-assembly-code-despite-using-gc%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password