ld failing to link my kernel

[prajwal]

Hi All,

I recently got a new Dell inspiron laptop on which I installed ubuntu linux os. Naturally, I wanted to continue my os development on this new system.

gcc version: gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.1
ld version: GNU ld (GNU Binutils for Ubuntu) 2.20

Compilation goes fine but when finally ld runs it throws following weird error:

ld: reopening o: No such file or directory

ld: final link failed: No such file or directory
make[1]: *** [aout] Error 1
make[1]: Leaving directory `/home/mosman/MOSDev/MOS'
make: *** [aout] Error 2

ld command I run is:

ld -o /home/mosman/MOSDev/MOS/bin/MOS.aout --oformat binary -Ttext=0 /home/mosman/MOSDev/MOS/boot/fpu_init.obj /home/mosman/MOSDev/MOS/boot/MOSStart_Main.grub ./drivers/DeviceDrive.o ......... <followed by around 30 more obj files>


There are no ld scripts being used. This was working perfectly fine on my previous laptop which was using (I think) 2.16 ld

the file format of first 2 files on the ld command line is aout (OMAGIC)
the file format of remaining all obj files is elf32-i386

Same is true with my previous laptop

Any help to resolve this issue is much appreciated

Thanks very much,
- MosMan

[prajwal]

I understand that the information provided is not very clear because the error itself is very unclear !

I further believe that the error comes when there is valid link error like undefined symbol. But instead of showing the actual error ld throws this error.
When I played around with adding and removing some obj files in ld command line, the actual error message came up. When I fixed the actual link error (undefined symbol), link succeeded. But, pretty much consistently the above error comes whenever there is an undefined symbol or other valid linker error

So, could this be a bug in ld on ubuntu os ?

Just hoping if this gives some clue to anyone to help resolve this issue...

Thanks,
- MosMan

[Grunt]

The Ubuntu patch for binutils is 33k lines. However, I didn't find anything related to "reopening" or "No such file", so I don't think it's because of that. You can check it here.

Have you tried running ld --verbose? That helped me when I was getting undefined symbols when trying to link with Newlib (because I was specifying libs before object files).

[jal]

Also, use a linker script. Really.


JAL

[prajwal]

Thanks very much for your responses.

I should confess that I am not an expert in using gnu ld. Though I tried your suggestions which wasn't very helpful in finding the problem

I tried re-ordering object files in the ld command line and it did the trick. The re-ordering I did was random and one of the combinations worked

So, is there any ordering convention that should be followed while specifying the list of object files to ld on the command line ?

Thanks,
- MosMan

[Combuster]

I saved you from this rant previously, but since you asked for it:

To be honest, your setup looks messed up in the first place - your makefile mentions a.out for an ELF toolchain. You use .o, .obj and .grub files as input, plus there's a ton more I can't see. You label output as a.out when its actually a flat binary file. You use deprecated object formats without purpose. All of this is not going to help you or anyone who tries to fix your stuff later (read: here).

In fact I'd personally throw away all the compilation scripts and remake them from scratch, as well as using a crosscompiler. If I actually did that, it'd probably work immediately and the commit log would sarcastically read "build system cleaned from code monkey poo", and I wouldn't care about what caused the problem originally.
</rant>

It's probably a good idea to read the Makefile and GCC Cross-Compiler articles, and then use the tools the way they were intended to be used. You should at least stop using a.out (If your assembler doesn't support ELF, it sucks by definition, get a better one)

[prajwal]

That's a real push to get up and fix it now !!!

Yeah. I totally agree with you. I am just being lazy to get more understanding of the build tools and get things into a decent shape.

ELF.... I like that ( and my OS supports ELF binaries ). This is my next real priority after basic USB support for mass storage and I am serious.

And naming it has a.out that's a joke from my side. It has that aout kludge for grub to load the kernel.... that made me to just name it a.out

Thanks very much for your suggestions.

Regards,
- MosMan

[NickJohnson]

Why would you need to use the a.out kludge to boot an ELF kernel with GRUB? It's called the a.out kludge for a reason, iirc.

[prajwal]

No. My kernel is not in ELF format. It's a flat binary. That's what combuster was mentioning it crazy for calling it aout when the kernel is a flat binary
To make grub load it, I have the aout kludge at the beginning

[bifferos]

I know this thread is about a year old, but it's the only google reference I could find for search for '"reopening o" gcc', so I thought I'd add something here in case it helps someone.

This comes up with gcc 4.4.4 often enough to be annoying. Yes, I have a linker script, it's very similar to the one on the wiki for C++ kernels. My kernel is a mixture of C++, C and Nasm (2.07) assembler.

Whether I link with g++ or ld I still get the error. A reliable way of getting rid of the error is to add the --verbose option to the linker, run the make from clean, then remove the --verbose option and then re-run the link. It works every time. I've no idea why.

Another way to remove the error is to change the order of the object files, actually I played around with it just now, and linking the Nasm objects last seemed to help a lot:

g++ $(LDLAGS) -o main.bin -Tmain_link.ld $(assobjs) $(objects) <failed>

g++ $(LDLAGS) -o main.bin -Tmain_link.ld $(objects) $(assobjs) <works>

I guess the problem may be references between the assembler object files and the linker script, the binary starts with a page-aligned head section that runs the constructors:

Code: Select all

OUTPUT_FORMAT("binary")

SECTIONS
{
. = 0x1800000;
  . = ALIGN(4096);
  .head : { 
        *(.head) 
  }

And that head section is Nasm. I suppose it's just possible Nasm is generating dodgy elf files, but surely someone would have spotted this?

So reordering the Nasm stuff so it's last on the g++ linker command-line seems to be working, for now.... however I've no idea why, and I'm sure this'll come back to bite me later on.

regards,
Biff.

[gerryg400]

There are bugs in some ports of LD (IIRC, windows ports) when flat binaries are output. Please try, as an experiment, removing that line from your linker script and see whether it behaves differently.

[bifferos]

There are bugs in some ports of LD (IIRC, windows ports) when flat binaries are output. Please try, as an experiment, removing that line from your linker script and see whether it behaves differently.

This was with gcc under Linux (Slackware 13.1), but yes, when ELF format is output it links OK and I don't get the error regardless of the link order. I then did an objdump -O binary, and that seems to give me back the same file I had before. I'll try with that for a while and see if the problem goes away, although this does come and go anyhow, so fingers crossed.

thanks for the suggestion,
Biff.

[gerryg400]

I always think it's better to produce an ELF file and then convert that to binary as a separate step anyway. ELF is good during debugging when you might want to inspect your code. You get more and better information from an ELF file.