Let me just install MX Linux to see if I can get the same result there.
Solved I can't assemble even the most basic file
- Thread starter James888
- Start date
Solved issue
Please don't worry about it. Like I said, I just need to know how to install the programming environment you mentioned.
The package names are different between deb based and rpm based, my output was from a RHEL clone which is rpm based. I'm just installing MX Linux in a vm to find out the package names so I can be sure I am giving you the right package names.
I installed MX Linux but I was able to link both programs on MX Linux(Xfce) without installing anything extra.
Code:
tux@mx:~/prog1
$ nasm -felf64 Example.asm
tux@mx:~/prog1
$ ld -o Example Example.o -ecrt0
tux@mx:~/prog1
$ ls -ltr
total 16
-rw-r--r-- 1 tux tux 46 Jun 15 19:04 Example.asm
-rw-r--r-- 1 tux tux 576 Jun 15 19:10 Example.o
-rwxr-xr-x 1 tux tux 4672 Jun 15 19:10 Example
Code:
tux@mx:~/prog1
$ rm Example.o Example
tux@mx:~/prog1
$ nasm -felf64 Example.asm
tux@mx:~/prog1
$ ld -o Example Example.o -lc -ecrt0
tux@mx:~/prog1
$ ls -tlr
total 24
-rw-r--r-- 1 tux tux 46 Jun 15 19:04 Example.asm
-rw-r--r-- 1 tux tux 576 Jun 15 19:11 Example.o
-rwxr-xr-x 1 tux tux 13584 Jun 15 19:11 ExampleAs said in my other reply the following packages sounds like the equivalent of the the two I mentioned in my other reply.
Since it sounds like that package provides both the headers and development libraries for glibc.
Last edited:
The only dev files I found were for headers, which I don't need and they are already on my computer. Actually I do need them but I translate the ones I need from h-files to inc-files. What I was hoping for was something that would automatically install
ld64.so.1 (or is it supposed to be ld-linux-x86-64)?
and not libc.so (since that is already installed and working).
Last edited:
More information...
GENERAL
$ whereis libc.so.6
$ whereis ld64.so.1
PROGRAM ONE
$ ldd Example
$ readelf -a Example | grep NEEDED
$ readelf -a Example | grep interpreter
$ objdump -d Example > x.asm
PROGRAM TWO
$ ldd Example
$ readelf -a Example | grep NEEDED
$ readelf -a Example | grep interpreter
$ objdump -d Example > x.asm
SYNOPSIS
The only thing that appears to be incorrect is the missing ld64.so.
GENERAL
$ whereis libc.so.6
libc.so: /usr/lib/x86_64-linux-gnu/libc.so /usr/lib/x86_64-linux-gnu/libc.so.6$ whereis ld64.so.1
ld64.so:PROGRAM ONE
$ ldd Example
not a dynamic executable$ readelf -a Example | grep NEEDED
$ readelf -a Example | grep interpreter
$ objdump -d Example > x.asm
Code:
Example: file format elf64-x86-64
Disassembly of section .text:
0000000000401000 <crt0>:
401000: e8 fb ff ff ff callq 401000 <crt0>
401005: b8 ff ff 00 00 mov $0xffff,%eax
40100a: c3 retqPROGRAM TWO
$ ldd Example
Code:
linux-vdso.so.1 (0x00007ffc6ffcc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fccec6ec000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007fccec8e9000)$ readelf -a Example | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]$ readelf -a Example | grep interpreter
[Requesting program interpreter: /lib/ld64.so.1]$ objdump -d Example > x.asm
Code:
Example: file format elf64-x86-64
Disassembly of section .plt:
0000000000401000 <.plt>:
401000: ff 35 02 20 00 00 pushq 0x2002(%rip) # 403008 <_GLOBAL_OFFSET_TABLE_+0x8>
401006: ff 25 04 20 00 00 jmpq *0x2004(%rip) # 403010 <_GLOBAL_OFFSET_TABLE_+0x10>
40100c: 0f 1f 40 00 nopl 0x0(%rax)
0000000000401010 <printf@plt>:
401010: ff 25 02 20 00 00 jmpq *0x2002(%rip) # 403018 <printf@GLIBC_2.2.5>
401016: 68 00 00 00 00 pushq $0x0
40101b: e9 e0 ff ff ff jmpq 401000 <.plt>
Disassembly of section .text:
0000000000401020 <crt0>:
401020: e8 eb ff ff ff callq 401010 <printf@plt>
401025: b8 ff ff 00 00 mov $0xffff,%eax
40102a: c3 retqSYNOPSIS
The only thing that appears to be incorrect is the missing ld64.so.
Ah, I see the problem there. I should have connected the dots on this much, much sooner.
If you take a look at the output of
But
So the fix for this is actually mind-numbingly simple.
You need to create an appropriately named symbolic link in
e.g.
That will create a symbolic link called
Run your program again and it should work!
I've verified this on my machine.
If you take a look at the output of
ldd in your post. The linker has set up the executable to use a symbolic link at /lib/ld64.so.1, which points to /lib64/ld-linux-x86-64.so.2.But
/lib/ doesn't contain a symbolic link with that name. So at runtime, during the setup stage, your program is failing to load the library and is throwing an error message.So the fix for this is actually mind-numbingly simple.
You need to create an appropriately named symbolic link in
/lib/, which points to /lib64/ld-linux-x86-64.so.2. And because it's in /lib/, you'll need to create the symbolic link as root.e.g.
Bash:
sudo ln -sT /lib64/ld-linux-x86-64.so.2 /lib/ld64.so.1ld64.so.1, which will point to the ld-linux-x86-64.so.2 shared object.Run your program again and it should work!
I've verified this on my machine.
Last edited:
Oops! My mistake! I just cut-and-paste your code into my terminal without looking at it. You have a typo. I fixed the typo and everything works. Thanks for the help!
Doh - I've corrected that typo now!
No worries. Happy to help!
First and foremost, I owe @James888 one more apology. Basically, they were right. My initial, superficial assessment of the problem was incorrect in several ways. I was cocky about how easy it would be to fix. I'll leave it at that.
The answer has been provided. I confirmed it here, too. I congratulate and thank the others for their contributions. I learned a lot today, not just related to this problem. That includes contriteness.
-> Congrats to James and to the helpers who jumped in for the persistence, great follow-through, and of course, the win.
Post Mortem:
I was in the process of running down similar paths as Jas, James, and "f33" regarding tools and linking and gcc. I had stumbled on how to get it to link without error, but I was working to make it run and display a string from the actual printf call. Unsuccessfully, I might add. It should have been easier.
I still want to finish a minimum printf console application in NASM that actually runs, mostly so I will know what I did wrong. (Thanks to James for informing us (me) about NASM. I have written assembler for a few processor targets, but had not known about NASM before today. That was an interesting lesson in itself. I know that my days of writing in assembly are in the past, but I enjoy learning for its own sake, too.)
MX Linux gave me fits as well. It was a clean install. There were no development tools, and I wanted to know which tools were the minimum necessary to solve James' problem. The open-vm-tools that I depend on to copy from the Linux virtual machine to my Mac (eek!) always worked ... until MX Linux. (Fortunately I had looked at MX Linux a few weeks ago for a future desktop system, not liked it very much, and ruled it out. I can see how it appeals to others.)
The answer has been provided. I confirmed it here, too. I congratulate and thank the others for their contributions. I learned a lot today, not just related to this problem. That includes contriteness.
-> Congrats to James and to the helpers who jumped in for the persistence, great follow-through, and of course, the win.
Post Mortem:
I was in the process of running down similar paths as Jas, James, and "f33" regarding tools and linking and gcc. I had stumbled on how to get it to link without error, but I was working to make it run and display a string from the actual printf call. Unsuccessfully, I might add. It should have been easier.
I still want to finish a minimum printf console application in NASM that actually runs, mostly so I will know what I did wrong. (Thanks to James for informing us (me) about NASM. I have written assembler for a few processor targets, but had not known about NASM before today. That was an interesting lesson in itself. I know that my days of writing in assembly are in the past, but I enjoy learning for its own sake, too.)
MX Linux gave me fits as well. It was a clean install. There were no development tools, and I wanted to know which tools were the minimum necessary to solve James' problem. The open-vm-tools that I depend on to copy from the Linux virtual machine to my Mac (eek!) always worked ... until MX Linux. (Fortunately I had looked at MX Linux a few weeks ago for a future desktop system, not liked it very much, and ruled it out. I can see how it appeals to others.)
Last edited:
I don't know how much assembly you know, but for NASM and Linux (the same as Windows) you need to know the ABI. Also, unlike most other assemblers, NASM doesn't use addr to get the address of an argument, you just type the function/variable name. So printf ("Characters: %c %c \n", 'a', 65); would become
stringName db "Characters: %c %c",0xA,0
mov rdi,stringName
mov rsi,'a'
mov rdx,65
call printf
NASM has no support for ABI, so you have to do it yourself. There is NASMx but it is poorly documented, has a very steep learning curve, and is too convoluted, so I wrote my own macros for that purpose.
Can you see how it would appeal especially to advanced Windows users? Everything I could do on Windows I can do on Mx Linux. My productivity and research is the same as it was for Windows, only my programming work is lagging behind.
As for the development environment, all I needed for windows was a programmer's editor (EditPad Pro), GoTools, and x64dbg. For Linux all I think I need is textAdept, NASM, the GNU compiler (for the linker only), and edb.
Last edited:
