Solved I can't assemble even the most basic file

[James888]

I am very new to Linux but I am not new to programming, so with that in mind understand me when I say that I cannot find anyone who can understand or help me with this super elementary programming problem so this is my last resort (which is why I didn't even know where to post this in this forum)...

PROGRAM ONE
;*************************************************************************** ; Assemble : nasm -felf64 Example.asm ; Link : ld -o Example Example.o -ecrt0 ;*************************************************************************** global crt0 section .text crt0: call crt0 ret

PROGRAM TWO
;*************************************************************************** ; Assemble : nasm -felf64 Example.asm ; Link : ld -o Example Example.o -lc -ecrt0 ;*************************************************************************** extern printf global crt0 section .text crt0: call printf ret

PROGRAM ONE will assemble and link without any errors or warnings, and disassembles correctly. PROGRAM TWO will assemble and link without any errors or warnings, but I cannot disassemble it because it won't load it, giving the error message "Failed to open and attach to process: execv() failed: No such file or directory". What file? What directory? There is not enough info given to troubleshoot this issue, there is very little info on the Internet concerning this issue, and what little there is disinformation or useless guessing. Funny thing is, if I change the link command for PROGRAM ONE to "ld -o Example Example.o -lc -ecrt0", it will fail the same as PROGRAM TWO.

NOTE:

I am using EDB for disassembly.
I am using Mx Linux, if that matters.
"whereis libc" shows libc is installed and working (of course).

Some related questions:

Is this a runtime issue? Do I need to setup some kind of developer environment for this to work?

What is missing from ALL the tutorials that they aren't telling us so this very elementary program will run?

 

[James888]

After an extensive search on Bing, Google, and Duck Duck Go, I finally found a credible and accurate source of information for this issue...

“No such file or directory” Error When Executing a Binary

https://www.baeldung.com/linux/no-such-file-or-directory-error

Baeldung is a "person" that I now know for a fact that I can trust for professional and accurate information.

The issue I am having according to Baeldung is that I am missing the program interpreter on Mx Linux. What this issue demonstrates with Linux in general is:

1. Certain error messages in Linux can be completely useless for resolving issues
2. You cannot troubleshoot the issue I am having with the information given, e.g. -- "Failed to open and attach to process: execv() failed: No such file or directory".

But now I have a new issue: I ran readelf -a Example | grep NEEDED and it told me I needed ld64.so.1. So I typed whereis ld64.so and it returned nothing, indicating that the library is not present on my computer. Ok, so where do I find ld64.so on the internet? Yuck! That doesn't sound like something fun to do considering my recent experience trying to find a solution to "Failed to open and attach to process: execv() failed: No such file or directory".

So, what do I do now? Where do I go to get this file for Mx Linux so Mx Linux will work properly? And why isn't this file already on Mx Linux, when it is such a vital file to have?

NOTE 1: I've been on the Mx Linux forum and they were extremely hostile towards me, so I'm not going back there to report any issues or ask for help. I searched but ld64.so is not listed in the Mx repository and I am very leery of downloading files from other sources I do not know for a fact I can trust (and yes you can download files requiring root access and install them yourself, but it can easily result in bricking your system, and I know this because I've already done this in the short four months I've been on Linux).

NOTE 2: I'm not saying I don't like Mx Linux nor am I criticizing Mx Linux in a non-constructive way. I am sticking with Mx Linux because it is an excellent OS in many other ways (including programmer development). Mx Linux has set the high-bar in my mind of what a Linux OS distribution should be like. But serious show-stopping issues like this cast doubt on the Linux community's commitment to the programmer or user migrating from Windows. I will never return to Windows because I do not trust Microsoft whatsoever, so I am committed to resolving issues and making this work, no matter what. So I want some serious, professional, accurate replies. Please.

 

[JasKinasis]

Where did you get these examples from?
If you let me know where you got these from, that might help me to help you.

FYI - I’m a professional C/C++ programmer. I’ve had varying amounts of experience with a lot of other programming and scripting languages. And I’ve been a Linux user for almost 20 years.

I haven’t done much with assembly in recent years. I don’t recognise the dialect you’re using there either. I’ve used Intel and AT&T assembly syntax in the past. And this doesn’t quite look like either of those.

I’m not near my PC right now either . But when I get home, I’ll try to take a look at your code. I’ll compile and link those two examples and see if I can work out what the problem is.

If the first program compiles and links ok but the second one doesn’t, then the problem is likely to be the -lc options you’re using for the second example. I can’t remember what that does offhand….. Either way, I’ll take a look when I’m home. A quick look at the man-page for nasm should get me back up to speed.

Watch this space!

 

[James888]

Where did you get these examples from?
If you let me know where you got these from, that might help me to help you.

They are elementary textbook examples that I wrote to illustrate this issue.

I haven’t done much with assembly in recent years. I don’t recognise the dialect you’re using there either. I’ve used Intel and AT&T assembly syntax in the past. And this doesn’t quite look like either of those.

If you don't recognize NASM syntax, I don't know if you will be able to understand the problem. The code is fine. There is nothing wrong with the code as proven by the fact Program One assembles and loads just fine.

If the first program compiles and links ok but the second one doesn’t, then the problem is likely to be the -lc options you’re using for the second example. I can’t remember what that does offhand…...

The Linux manual defines -l as,

Add the archive or object file specified by namespec to the list of files to link ... Specifically, on ELF and SunOS systems, ld will search a directory for a library called libnamespec.so before searching for one called ibnamespec.a. (By convention, a ".so" extension indicates a shared library.) Note that this behavior does not apply to :filename, which always specifies a file called filename

Therefore -lc should translate as "link libc.so to Example executable". As readelf indicates, that seems to work, so I don't understand (yet) why it is also trying to link ld.so, which doesn't exist and wasn't mentioned in my code or CLI options, other than as a command to compile and link Example.o to Example.

 

[wizardfromoz]

James, you are new here, so with

If you don't recognize NASM syntax, I don't know if you will be able to understand the problem.

Dial it back a little. Jas lives in England and is likely catching zzz's right now, he will be back with you when he can.

Jas is, what we call in an understated way here in Australia

"good value"

In the meantime, I will tell you what I know, but this is beyond my paygrade, so I urge you to wait until Jas is back to qualify what I have to show before acting on it. At the very least, install Timeshift and take a full snapshot before you act, so you can roll back if things go wrong.

I am using Mx Linux, if that matters.

It likely does. If you are using MX-21, I found this with a search on ld64.so.1 at pkgs.org under Debian Sid:

ld64.so.1 is a part of two (2) packages called

libc6-ppc64-cross_2.36-8cross1_all.deb

and

libc6-s390x-cross_2.36-8cross1_all.deb

which are described as GNU C Library: Shared libraries (for cross-compiling)

You can download with the following

wget http://ftp.de.debian.org/debian/pool/main/c/cross-toolchain-base-ports/libc6-ppc64-cross_2.36-8cross1_all.deb

OR

wget http://ftp.de.debian.org/debian/pool/main/c/cross-toolchain-base/libc6-s390x-cross_2.36-8cross1_all.deb

I do not know which is more appropriate, so as I say, wait for Jas, or he may (likely) have other ideas. Listen to them.

I can help with any questions you might have on Timeshift here

My Timeshift Thread

If you go there, page 17 is where to ask.

Cheers

Wizard

 

[wizardfromoz]

BTW the 2 Sid packages are compatible with MX-21 because in my MX my output from a search was as follows

$ apt policy libc6-ppc64-cross
libc6-ppc64-cross:
  Installed: (none)
  Candidate: 2.36-8cross1
 
  #and
 
  chris@MX21RC-SSD:~
$ apt policy libc6-s390x-cross
libc6-s390x-cross:
  Installed: (none)
  Candidate: 2.36-8cross1

... so, another option to get them is from your Repositories with

sudo apt install <name_of_package>

Wizard

 

[James888]

In the meantime, I will tell you what I know, but this is beyond my paygrade, so I urge you to wait until Jas is back to qualify what I have to show before acting on it. At the very least, install Timeshift and take a full snapshot before you act, so you can roll back if things go wrong.

That sounds scary. Remember what I said about being new to Linux? I wasn't exaggerating, and what you are suggesting sounds scary. I went through 10 different alternate OSes (including a few Linux ones like Deepin) before settling on Mx Linux. And I'm talking about since mid-February until today. So I'm not sure I want to try something like that until I'm a little more advanced user.

wget http://ftp.de.debian.org/debian/pool/main/c/cross-toolchain-base-ports/libc6-ppc64-cross_2.36-8cross1_all.deb

OR

wget http://ftp.de.debian.org/debian/pool/main/c/cross-toolchain-base/libc6-s390x-cross_2.36-8cross1_all.deb

That is not an official package from Mx Linux. Remember what I said about bricking Linux? I wasn't lying. Now I'm overly-careful with what I do. I am not rejecting your advice, I'm just going to take some time before I do it because it seems too risky to me.

A SHORT STORY MADE LONGER: I was on Deepin and they didn't have any good programs in their official repository. So I downloaded Synaptic Package Manager and it was like being a little child in a candy store, and I was downloading everything and trying it out. But that is dangerous behavior. I found out that some programs install ok, but they won't uninstall ok. Deepin became unstable and I didn't know why, but that was the reason. Then I discovered I could add additional repositories to SPM to get even more programs. That was a huge mistake. One repository updated my libc to the very latest and greatest version. I deleted that program and that repository, but libc remained at the very latest version. I could not uninstall it and I didn't know how to overwrite it, and many of my programs stopped running because of the wrong version of libc. I had to reinstall Deepin.

So no more risky behavior from a very dangerous Linux noobie like me. Maybe

 

[wizardfromoz]

I've put a Love on that, because it is prudent to be cautious as you learn what is compatible and what is not. And coming from someone (me) who has ADD/ADHD, I can well understand

So I downloaded Synaptic Package Manager and it was like being a little child in a candy store, and I was downloading everything and trying it out. But that is dangerous behavior. I found out that some programs install ok, but they won't uninstall ok.

In #8 above, my BTW, I explained that I found that the 2 packages are both in the Repositories for MX. Maybe just confirm that you are using MX-21?

MX Linux draws on two (2) Repositories (hereafter referred to as Repos)

• its own, MX, repos and
• Debian's repos

Downloading them is safe, installing them is safe. What you do with them, I have no idea.

I have been using Linux for 13 years, and exclusively for 9 years (no Windows), but I still blow things up from time to time, hence the use of Timeshift. I have it on all 77 of the Linux distros I run. As my fellow Australian and good friend Brian @Condobloke says -

Timeshift is similar to system restore in windows. The fundamental difference is that Timeshift works

Cheers

Wizard

 

[James888]

Time for me to let my Linux noobie character shine...

wget only downloads a file, it does not tell you where it needs to be installed. I need to research that some more.

One more piece of the puzzle I discovered:

$ ldd ./Example
        /lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007fee01fdc000)

Say what?! I need to research that some more. I'm not sure how to interpret that other than it might be a symbolic link that the linker used but Mx Linux does not. That's just a wild arse guess though.

Anyone know about these things off the top of their head and shorten my learning curve? It could save me hours or even days of research, especially when there is so much disinformation about Linux issues on the Internet that have to be waded through to get to the real thing.

PS -- Warning! I am an assembly language systems programmer and that means I go through EVERYTHING with a fine-tooth comb. If that sounds anal, it is because it is anal. When you program in assembly, you have to go though excruciating detail in everything you do to make sure you get things right. I apologize if that rubs anyone the wrong way.

"I'm not bad, I'm just drawn that way" (Jessica Rabbit).
"I'm not anal, I'm just drawn that way" (James888).

 

[JasKinasis]

They are elementary textbook examples that I wrote to illustrate this issue.

In that case, the problem is almost certainly something you’re doing incorrectly.

If you don't recognize NASM syntax, I don't know if you will be able to understand the problem. The code is fine. There is nothing wrong with the code as proven by the fact Program One assembles and loads just fine.

Ha ha, OK kid!
Like I said, it’s just been a while since I used nasm.

I recognised the section headers, it’s just the rest of the code looks a little unusual to me (not that there is a lot of code there.)

The first example really isn’t doing a whole lot, that compiles and links with no problems for me too.

The second example compiles with nasm, but fails to link with ld. This appears to be because it can’t find the printf function, which is a C standard library function.

After posting last night, I realised that the -lc flag was the linker flag for the C standard library, to allow printf to be used.
And I knew that your -e flag was defining the entry point for your program, which in your case was "crt0:", instead of the default "main:" label.

I wonder if the problem is due to the fact that the printf function takes parameters? Your code does not provide any string data/parameters to the printf function. Because there are no parameters being sent, perhaps the linker is looking in the library for a printf function that takes no parameters. And because it can’t find an implementation of printf that matches that signature, the linker is throwing an error?! Perhaps?!

That was my initial thought.

However, I grabbed a slightly more substantial hello-world nasm example from a random spot on the internet. One that uses printf. I tried to compile and link that.
It compiles ok with nasm, but it still wouldn’t link using ld. I forget what the exact error was. However, I tried using gcc to link it instead - and it successfully linked.
And then the final executable ran, but it didn’t show any of the expected "hello world!" output for me…. Hmmmm….. Perplexing…. I didn’t get time to run it through gdb to see what was going on either.

The last time I used nasm seriously was back when things were still 32bit. I wrote a load of short programs using Linux syscalls/int 80 interrupts. So it was a while ago. I doubt any of my old assembly programs will build on 64 bit, at least, not without a little bit of modification!

Anyway, I’m away from my PC again ATM. When I get home, I’ll share the code for the example I tried to build today (along with the link where I found it).

 

[sphen]

I have some small experience with assembler and C. I have never written code in NASM, but don't insult me for it. The original post is clear to me and I was not confused by the code or the linking errors. I understand James' issues anyway. There are several.

I installed an MX Linux XFCE but I do not know why I bothered. The issues are plain and obvious from looking at the original post. With the installation, I replicated @James888's situation easily.

• Both Program One and Two are incomplete and incorrect.
  • Program One is an endless loop where crt0 calls itself.
  • Program Two tries to call printf, but without setting up the registers for the call.
    • There is no string to print, for example.
  • Neither program has the elements necessary to create a Linux executable.
• The "extern printf" statement in Program Two implies that the code is intended to be linked into the C runtime environment.
  • The necessary library is not mentioned in the Program Two link command.
• Based on my understanding of the intent of the author, the crt0 label in both programs should be different.
  • Crt0 is "reserved" as the entry point for the executable to launch, and that entry point is supplied by the C libraries.
  • https://en.wikipedia.org/wiki/Crt0

I could fix the code and make it work, but have already invested too much time, so sorry.

With respect, it appears that James has not yet mastered the basic steps required to write the usual "hello world" program in NASM and linked to the C libraries, to create a basic executable that can run on a typical Linux system. I outlined the steps necessary to fix James' issues in this post.

I started this post much earlier this morning, but had interruptions, so there is overlap between the posts. I saw the text above saying, "Warning! I am an assembly language systems programmer and that means I go through EVERYTHING with a fine-tooth comb. ..."

Perhaps James wants to do everything in assembler but needs some more experience in this kind of runtime usage. Honestly, it is entry-level student material. Otherwise, I assume that James is withholding information. The original post lacks essential details.

 

[James888]

In that case, the problem is almost certainly something you’re doing incorrectly.

Well that solves the problem

Ha ha, OK kid!
Like I said, it’s just been a while since I used nasm.

I recognised the section headers, it’s just the rest of the code looks a little unusual to me (not that there is a lot of code there.)

The first example really isn’t doing a whole lot, that compiles and links with no problems for me too.

The second example compiles with nasm, but fails to link with ld. This appears to be because it can’t find the printf function, which is a C standard library function.

Finding libc isn't the problem, not being able to run at all is the problem.

After posting last night, I realised that the -lc flag was the linker flag for the C standard library, to allow printf to be used.
And I knew that your -e flag was defining the entry point for your program, which in your case was "crt0:", instead of the default "main:" label.

I wonder if the problem is due to the fact that the printf function takes parameters? Your code does not provide any string data/parameters to the printf function. Because there are no parameters being sent, perhaps the linker is looking in the library for a printf function that takes no parameters. And because it can’t find an implementation of printf that matches that signature, the linker is throwing an error?! Perhaps?!

It doesn't matter, the program is just nonsense code and wasn't intended to run, it was just intended to illustrate the issue that it won't load.

That was my initial thought.

However, I grabbed a slightly more substantial hello-world nasm example from a random spot on the internet. One that uses printf. I tried to compile and link that.
It compiles ok with nasm, but it still wouldn’t link using ld. I forget what the exact error was. However, I tried using gcc to link it instead - and it successfully linked.
And then the final executable ran, but it didn’t show any of the expected "hello world!" output for me…. Hmmmm….. Perplexing…. I didn’t get time to run it through gdb to see what was going on either.

The last time I used nasm seriously was back when things were still 32bit. I wrote a load of short programs using Linux syscalls/int 80 interrupts. So it was a while ago. I doubt any of my old assembly programs will build on 64 bit, at least, not without a little bit of modification!

Anyway, I’m away from my PC again ATM. When I get home, I’ll share the code for the example I tried to build today (along with the link where I found it).

This isn't a coding issue, it is a linking issue. PROGRAM ONE is ok, not because it runs but because it can be loaded into EDB. PROGRAM TWO is not ok, despite a very minor difference, not because it could run, but because it can't be loaded into EDB.

 

[sphen]

P.S. James - Try typing these commands and look at the output. I named Program One "program1.asm":

• nasm -felf64 program1.asm
• ld -o program1 program1.o -ecrt0
• objdump -Mintel -d program1

Sorry, but open-vm-tools is broken on that MX Linux I installed, and I don't have the patience to figure it out. I grabbed a screenshot - quick 'n' dirty, but hopefully it shows the results for others:

 

[sphen]

Why would I want to insult you? You're not warning me that you are going to say something that would make me want to insult you, are you? If that is the case, I will block you.

Because I saw your comment to @JasKinasis. Block me or not, but I am moving on.

The issue isn't if the code will run or not, nor is it if the code is correct or not, the issue is why will PROGRAM ONE assemble, link, and load into EDB, but PROGRAM TWO will assemble and link, but it won't load into EDB because of a mysterious "file or directory missing" error? Address that issue because that is the only actual issue here.

Okay - It is because you declared printf as an extern in your source code, but the linker does not know what to do with that declaration at link time. You did not provide an object file or library with "printf" in it for the linker to resolve.

The "extern" declaration tells the assembler that the definition of "printf" is not in the current source file and will be supplied from elsewhere in the code in another file. (It implies that printf is in another file, and it will get resolved at link time.)

NASM labels can be anything you want, the only reserved label is _start. This also has nothing to do with the issue presented here.https://en.wikipedia.org/wiki/Crt0

With respect, I disagree. Your use of the label "crt0" in your source code will cause problems when you try to make it work as a executable. Reminding you that "printf" makes me believe that this will be a typical Linux console application that relies on the normal C runtime environment.

Adding, a few minutes later:
1. The label "crt0" may not be reserved, but it will generate an error at link time. The linker will find two definitions of "crt0". (Once again, assuming a typical Linux executable.)

2. It would help if you could confirm that I am correct, and the "printf" call is the one that C programs all use. It implies that this is a typical Linux console application linked to the C runtime environment. That would make it a typical console application written in assembler for Linux.
-> Am I correct?

The code was only written as background filler (I could have just put nothing but nops , but I needed to illustrate the fact that a call works but only if it isn't global). You want to help? Show us how you can make ld load into edb, whether or not the code was intended to run or not.

Really. From someone who just threatened to block me? It should not be difficult. Do a search like "hello world in NASM" or something like that. Someone must have posted a working example somewhere on the internet for you to find. If you still do not find what you need, reply here and I will find it for you.

 

[KGIII]

Remember, civility is a two way street and is the rule of law around here.

Further, being ungrateful to the folks trying to help is just bad manners. Please don't make me do moderator-type things. Thanks.

 

[James888]

I wonder if the problem is due to the fact that the printf function takes parameters? Your code does not provide any string data/parameters to the printf function. Because there are no parameters being sent, perhaps the linker is looking in the library for a printf function that takes no parameters. And because it can’t find an implementation of printf that matches that signature, the linker is throwing an error?! Perhaps?!

That was my initial thought.

However, I grabbed a slightly more substantial hello-world nasm example from a random spot on the internet. One that uses printf. I tried to compile and link that.
It compiles ok with nasm, but it still wouldn’t link using ld. I forget what the exact error was. However, I tried using gcc to link it instead - and it successfully linked.
And then the final executable ran, but it didn’t show any of the expected "hello world!" output for me…. Hmmmm….. Perplexing…. I didn’t get time to run it through gdb to see what was going on either.

Before I forget, I want to go out of my way to publicly say thank you sir for validating the issue by running and confirming the issue for me. The effort you took to understand the issue is very much appreciated and that effort alone could help me in other ways. So again, thank you.

PS -- I tried using GCC too, but that only made things worse. Also, GCC is much harder and more convoluted for doing things with object files instead of source code, so like the vast majority of Linux asm programmers, I'm sticking with the GNU linker for all my NASM needs. Still though, I am curious what your command line parameters were for PROGRAM TWO since I'm not sure I got that right?

 

[f33dm3bits]

PROGRAM ONE will assemble and link without any errors or warnings, and disassembles correctly. PROGRAM TWO will assemble and link without any errors or warnings, but I cannot disassemble it because it won't load it, giving the error message "Failed to open and attach to process: execv() failed: No such file or directory". What file? What directory? There is not enough info given to troubleshoot this issue, there is very little info on the Internet concerning this issue, and what little there is disinformation or useless guessing. Funny thing is, if I change the link command for PROGRAM ONE to "ld -o Example Example.o -lc -ecrt0", it will fail the same as PROGRAM TWO.

Programming is not my area but I will try and just give my two cents, did you install glibc-headers and glibc-devel or the equavalant packages on MX Linux?
I am successfully able to assemble and link program one but program2 I am only able to assemble but not link. When I link I get the following error.

[root@rocky9-test prog2]# ld -o Example Example.o -lc -ecrt0
ld: cannot find -lc

After installing glibc-headers.x86_64 glibc-devel.x86_64 I am able to link.

[root@rocky9-test prog2]# nasm -felf64 Example.asm
[root@rocky9-test prog2]# ld -o Example Example.o -lc -ecrt0
ld: cannot find -lc
[root@rocky9-test prog2]# ls -tlr
total 8
-rw-r--r--. 1 root root  62 Jun 15 18:15 Example.asm
-rw-r--r--. 1 root root 704 Jun 15 18:27 Example.o

[root@rocky9-test prog2]# dnf install glibc-headers.x86_64 glibc-devel.x86_64

[root@rocky9-test prog2]#  ld -o Example Example.o -lc -ecrt0
[root@rocky9-test prog2]# ls -tlr
total 24
-rw-r--r--. 1 root root    62 Jun 15 18:15 Example.asm
-rw-r--r--. 1 root root   704 Jun 15 18:27 Example.o
-rwxr-xr-x. 1 root root 14192 Jun 15 18:29 Example

 

[sphen]

... and I was uncivil. I want to share an apology to all, and specifically to @James888 for that. Sorry. :-(

. . . . .

Back on topic, I did not give the "-lc" in the second link command sufficient scrutiny.

I reran the code and looked at the object dump from the link output. You can still see the problems with the application, but it did add more for the C runtime. @JasKinasis comment regarding using gcc linker is also worth exploring.

I won't be able to look at it again for a few hours I'll be back ...

 

[James888]

Programming is not my area but I will try and just give my two cents, did you install glibc-headers and glibc-devel or the equavalant packages on MX Linux?

This is hilarious! Programming is not your area of expertise but I think you may have hit the nail on the head. I am a programming "expert" but I am a Linux noobie, so I didn't know if I need to do that and I certainly don't know how to do that. You are more of an expert than me on this, so tell me what I need to do? Please?

I am successfully able to assemble and link program one but program2 I am only able to assemble but not link. When I link I get the following error.

 prog2]# ld -o Example Example.o -lc -ecrt0
ld: cannot find -lc

After installing glibc-headers.x86_64 glibc-devel.x86_64 I am able to link.

[root@rocky9-test prog2]# nasm -felf64 Example.asm
[root@rocky9-test prog2]# ld -o Example Example.o -lc -ecrt0
ld: cannot find -lc
[root@rocky9-test prog2]# ls -tlr
total 8
-rw-r--r--. 1 root root  62 Jun 15 18:15 Example.asm
-rw-r--r--. 1 root root 704 Jun 15 18:27 Example.o

[root@rocky9-test prog2]# dnf install glibc-headers.x86_64 glibc-devel.x86_64

[root@rocky9-test prog2]#  ld -o Example Example.o -lc -ecrt0
[root@rocky9-test prog2]# ls -tlr
total 24
-rw-r--r--. 1 root root    62 Jun 15 18:15 Example.asm
-rw-r--r--. 1 root root   704 Jun 15 18:27 Example.o
-rwxr-xr-x. 1 root root 14192 Jun 15 18:29 Example

I don't understand what you are saying here. readelf demonstrates for me that Linux can find and link to glibc just fine, it just won't run or load the program, as if the program itself didn't exist. Baeldung help me prove that it was some kind of linker problem, and I wasn't sure if I needed to setup some kind of "developer environment" because in Windows that isn't necessary for asm programming.

 

[f33dm3bits]

To add to my other reply.
Program1: assembling and linking.

[root@rocky9-test prog1]# nasm -felf64 Example.asm
[root@rocky9-test prog1]# ld -o Example Example.o -ecrt0
[root@rocky9-test prog1]# ls -tlr
total 16
-rw-r--r--. 1 root root   46 Jun 15 18:14 Example.asm
-rw-r--r--. 1 root root  576 Jun 15 18:40 Example.o
-rwxr-xr-x. 1 root root 4672 Jun 15 18:40 Example

Program1: linking with -lc option as you did with program2.

[root@rocky9-test prog1]# ld -o Example Example.o -lc -ecrt0
ld: cannot find -lc

[root@rocky9-test prog1]# dnf install glibc-headers.x86_64 glibc-devel.x86_64

[root@rocky9-test prog1]# ld -o Example Example.o -lc -ecrt0
[root@rocky9-test prog1]# ls -tlr
total 24
-rw-r--r--. 1 root root    46 Jun 15 18:14 Example.asm
-rw-r--r--. 1 root root   576 Jun 15 18:40 Example.o
-rwxr-xr-x. 1 root root 13584 Jun 15 18:43 Example