Why HP-UX must use its own linker for gcc?

[ranganath ramachandra]

gcc got misled by the unexpected content in the file and considered it an object file, so passed it to the linker; the linker in turn took it for an instrumented object file to be (re-)processed by the compiler backend - that is the case when it tried to load libucomp.so .

how did you locate the problem?

[Dennis Handly · Accepted solution]

> It seems that the original source filename (scsi_test.c) was wrong with some invisible characters.

Yes, that would confused the driver if it didn't end in ".c".  cc(1)/c99(1) work the same way.

> I still do not understand why gcc would report such ld libu2comp.so error under this situation

Because ld(1) is broken and doesn't make sure it is an ELF file.

> the linker in turn took it for an instrumented object file to be (re-)processed by the compiler backend - that is the case when it tried to load libucomp.so .

Wasn't this fixed years ago?

> how did you locate the problem?

Well, the source file was listed on the verbose ld output.  :-)

[ranganath ramachandra]

---

@Dennis Handly wrote:

> It seems that the original source filename (scsi_test.c) was wrong with some invisible characters.

Yes, that would confused the driver if it didn't end in ".c".  cc(1)/c99(1) work the same way.

> I still do not understand why gcc would report such ld libu2comp.so error under this situation

Because ld(1) is broken and doesn't make sure it is an ELF file.

> the linker in turn took it for an instrumented object file to be (re-)processed by the compiler backend - that is the case when it tried to load libucomp.so .

Wasn't this fixed years ago?

At least now.

[ cathh02 tmp ] $ gcc -Wl,-V test.cx
ld: 92453-07 linker ld HP Itanium(R) B.12.63 IPF/IPF
ld: Mismatched ABI (not an ELF file) for test.cx
Fatal error.
collect2: error: ld returned 1 exit status

I got the same results with 12.58, couldn't find 12.61 though.

[liuyl_it]

I noticed the following error message that returned via gcc -c :
gcc: scsi_test.c: linker input file unused because linking not done

Then the below related post at stackoverflow should implied what cause my problem might be due to!
https://stackoverflow.com/questions/10739072/gcclinker-input-file-unused-because-linking-not-done

But I still really cannot explain why the source file was listed on the verbose ld output.

By the way,  it seems that the earlier version of binutils for HP-UX provided the GNU linker long ago！

[Dennis Handly]

> But I still really cannot explain why the source file was listed on the verbose ld output.

Because it's not a source file because it doesn't end in ".c".  You said there was junk on the end?

ll -b will show the unprintable chars.

[liuyl_it]

Now I wonder what the other error messages would be returned via ld with the same problematic source file  if the system has installed with the shared library of libu2comp.so ？

[ranganath ramachandra]

---

@liuyl_it wrote:

Now I wonder what the other error messages would be returned via ld with the same problematic source file  if the system has installed with the shared library of libu2comp.so ？

---

As long as the file is properly named, any errors that can be detected with the installed compilter would be reported already.

If the file is not named correctly, error reports may not be reliable. So don't bother about the errors when the file is incorrectly named.

From the compiler manual page cc_bundled(1):

 Other Suffixes
             All other arguments, such as those names ending with .o,
             .a, or .so are taken to be relocatable object files and
             are passed to ld (see ld(1)) to be included in the link
             operation.

 The behaviour of the linker for unrecognized input formats seems to be undocumented.

[liuyl_it]

These days I have searched the knowledges for the instrumented object/code/execution！
But I just only found few information about them including the following reference link:

https://www.sharcnet.ca/Software/Intel/IFC/compiler_f/main_for/copts/common_options/option_prof_gen.htm

So could you tell me the significance of the "instrumented object file"  concept in my this issue？

[ranganath ramachandra]

---

So could you tell me the significance of the "instrumented object file"  concept in my this issue？

---

In your case there is no instrumented object file. Because of the bad filename, the compiler passed the source file to the linker. The linker mistakenly assumed it to be an instrumented object file. If your original problem goes away after renaming the source file, you don't have to bother about it any more.