ld hates my nasm...

[jimi_hendrix]

so i have a hello world program but i get this output:

ld: i386 architecture of input file `hello.o' is incompatible with i386:x86-64 output

how can i fix this (please give sample commands to compile/link)

but if i dont specify the program as 64bit then i get

ld: i386 architecture of input file `hello.o' is incompatible with i386:x86-64 output

[NathanB]

Did you not tell NASM to give an ELF64 style object format??

[NathanB]

Also, always get (and build from scratch) your development tools from the latest source:

http://www.nasm.us/

The .deb package in the 64-bit Ubuntu repository {the last time I checked} is a very buggy version that was never intended for distribution. ([soapbox] the price one pays for relying on a popular "distro" [/soapbox])

[sandcrawler]

I just started playing with asm again... Here's what I found....

using the tutorial HERE I copied their asm hello world code

assembled the code into an object

nasm -f elf hello.asm

then tried to link it...

ld -s -o hello hello.o

I got the same error as you... After much searching I found the key to getting 32bit code to run on x86_64 IN THIS CASE ONLY is as simple as

ld -melf_i386 -s -o hello hello.o

Further reading indicates having to specify something like BITS 16, 32 or 64 in the asm and which opcodes are expected when doing so. That's all far above me right now and may well be more than I care about since I'm primarily learning asm to improve my hacking skills. (I'm a CEH, so this is all legit )

Edit 2: I also found you can adjust the output format from nasm and compile the code in the sample url to run in 64 bit

nasm -f elf64 hello.asm
ld -s -o hello hello.o

P.S. I'm running gentoo, not Ubuntu so you may need to load whatever packages Ubuntu provides for 32 lib emulation.

[Ishipaco]

I encountered the same problem when trying to assemble and link programs in Jeff Duntemann's Assembly Language, Step By Step. I'm running Ubuntu 10.4 with the Gnome desktop. Here's what finally worked for me:

Note: See my later post of 2010-08-27 for a link to a clearer (than what follows here) explanation of the problem and its solution.
=========================================
Although the error message occurs when trying to link, the problem is with the format of the <filename>.o file generated by nasm. Duntemann's instructions say to assemble with the -f elf option (same as -f elf32). This generates an object file that the linker will reject on a 64-bit kernel and platform. First, to see what the various output formats are available, run this code (the "$" is your prompt; don't type it):

$ nasm -hf

Among other info, this will show you a long list of the various object file outputs that you can use. Then, to create an object file that will run on a 64-bit machine, I entered the next three commands:

$ nasm -f elf64 -g -F stabs <filename>.asm
$ ld -o <filename> <filename>.o
$ ./<filename>

The last command, of course, simply runs the program to test it. BTW, you will probably have to delete the original <filename>.o file before doing this process, as the assembler will think the object module is already up to date and won't create a new one. Finally, if you're using a make file to run the process, be sure to edit the options for assembly in that file too, or you'll get the same errors as before.

Another option that worked for me is to use -f elf to assemble and then add an option to the ld command on the command line or in your make file, like so:

$ nasm -f elf -g -F stabs <filename>.asm
$ ld -o <filename> <filename>.o -melf_i386
$ ./<filename>

I believe the first solution generates 64-bit native code, while the second creates 32-bit code that will run on a 64-bit platform. Please correct me if anyone knows this to be wrong.

Hopes this helps people running Ubuntu.

[Ishipaco]

This problem has been circulating on the forums of late and usually concerns people studying assembly language, using Jeff Duntemann's book, Assembly Language, Step by Step, 3rd edition, 2009.

I've created a static webpage that explains the problem and its solutions in more depth (and better than I did in my first post here!), especially useful to followers of Jeff's book. You can access it here (along with other book issues):

http://www.stepbystep.ishipaco.com/#question1

Jeff has posted (as of 2010-08-25) his comments on this problem (among other discussions) on his website:

http://www.duntemann.com/assembly.html

Understanding and solving this issue is a valuable and useful lesson for all of us interested in assembly language programming (all five of us? Hi hi).

--73