Operating System - HP-UX
1748204 Members
3710 Online
108759 Solutions
New Discussion

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

 
SOLVED
Go to solution
liuyl_it
Frequent Advisor

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

18 REPLIES 18
Dennis Handly
Acclaimed Contributor

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

For what architecture?  For PA32, it uses SOM format, not ELF.

For PA64 and Integrity, it uses ELF.

What fancy features do you need from GNU ld?

liuyl_it
Frequent Advisor

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

Because the linker for HP-UX itself must use the following shared library file!
And this file libu2comp.so is just bundled with the HP-UX aCC commercial software!

# gcc scsi_test.c -o scsi_test
ld: Unable to load shared library "/opt/langtools/lib/hpux64/libu2comp.so"
Fatal error.
collect2: ld returned 1 exit status

Notes: There is also no GNU linker within the binutils for either IA/PA64 or PA32!

Dennis Handly
Acclaimed Contributor

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

> Because the linker for HP-UX itself must use the following shared library file

This is a user error and it's not true.  Newer lds were suppose to have an error message saying mixing PA32 with ELF.

> # gcc scsi_test.c

Compile with -c and use "file scsi_test.o" to see what the architecture is.  Are you trying to build PA32 on Integrity?


>There is also no GNU linker within the binutils for either IA/PA64 or PA32

Why would you need one?

liuyl_it
Frequent Advisor

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

1) It is directly built on IA64:
#
# file scsi_test.o
scsi_test.o: ELF-32 relocatable object file - IA64
#

And referring to the following posts:
https://community.hpe.com/t5/General/from-PA-RISC-to-Itanium-Unable-to-load-shared-library/td-p/4866432   <<<< no this cause
https://community.hpe.com/t5/Languages-and-Scripting/Unable-to-load-quot-libu2comp-so-quot/td-p/6971384  <<<< this might be

 

2) I think that the GNU linker should not use this shared library file that bundled with HP-UX aCC!
Notes: It seems that the GNU linker integrates with the binutils for the most UNIXes except HP-UX!

Dennis Handly
Acclaimed Contributor

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

> 1) It is directly built on IA64:  scsi_test.o: ELF-32 relocatable object file - IA64

Ok but there may be other objects that confuse ld(1).

Note: Your URLs contain junk chars on the end.  You can fix that by editing your post with Edit Reply and using the hyperlink menu to edit them.
https://community.hpe.com/t5/General/from-PA-RISC-to-Itanium-Unable-to-load-shared-library/td-p/4866432 <<<< no this cause

This could be a case where that shlib was actually needed to optimize?


https://community.hpe.com/t5/Languages-and-Scripting/Unable-to-load-quot-libu2comp-so-quot/td-p/6971384  <<<< this might be

Yes, here is where I explain how to find the bad object:

https://community.hpe.com/t5/Languages-and-Scripting/Unable-to-load-quot-libu2comp-so-quot/td-p/6971384#U6972297

 > 2) I think that the GNU linker should not use this shared library file that bundled with HP-UX aCC

That's not the problem.  The problem is that ld(1) is not giving you an error when you're passing in the wrong architecture objects, archives or shlibs.

liuyl_it
Frequent Advisor

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

1) Bad object ?

#
#
# export LDOPTS="+vtype files"
#
#
# gcc scsi_test.c -o scsi_test_sp
Loading /usr/lib/hpux32/unix98.o:
ld: Unable to load shared library "/opt/langtools/lib/hpux64/libu2comp.so"
Fatal error.
collect2: ld returned 1 exit status
#
#
#
# ls -l /usr/lib/hpux32/unix98.o
-r--r--r-- 1 bin bin 1560 Jan 21 2014 /usr/lib/hpux32/unix98.o
#
#
#
# export LDOPTS="-V -T"
#
#
# echo $LDOPTS
-V -T
#
#
# gcc scsi_test.c -o scsi_test_sp
ld: 92453-07 linker ld HP Itanium(R) B.12.61 IPF/IPF
ld: Unable to load shared library "/opt/langtools/lib/hpux64/libu2comp.so"
Fatal error.
collect2: ld returned 1 exit status
#
#

Dennis Handly
Acclaimed Contributor

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

> Loading /usr/lib/hpux32/unix98.o:
> ld: Unable to load shared library "/opt/langtools/lib/hpux64/libu2comp.so"

This indicates that unix98.o is bad but I'm not sure how.

Trying using "-Wl,-v" with gcc, to have linker verbose output.  I only need to see first 10 or so lines.

And next step is to use gcc to compile your object but link with cc.

liuyl_it
Frequent Advisor

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

Now this time I feel that we might find the hidden problem soon ......!

#
#
# gcc -Wl,-v scsi_test.c -o scsi_test_exec
collect2 version 4.3.1 (IA-64) HP-UX
/usr/ccs/bin/ld -z +Accept TypeMismatch -u main -o scsi_test_exec /usr/lib/hpux32/unix98.o -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1 -L/usr/ccs/lib -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../.. -v scsi_test.c -lgcc -lgcc_eh -lunwind -lc -lgcc -lgcc_eh -lunwind
/usr/ccs/bin/ld -z +Accept TypeMismatch -u main -o scsi_test_exec /usr/lib/hpux32/unix98.o -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1 -L/usr/ccs/lib -L/opt/hp-gcc-4.3.1/lib/gcc/ia64-hp-hpux11.23/4.3.1/../../.. -v scsi_test.c -lgcc -lgcc_eh -lunwind -lc -lgcc -lgcc_eh -lunwind
LPATH is :
Loading /usr/lib/hpux32/unix98.o:
/usr/lib/hpux32/unix98.o:
__xpg4_extended_mask is DEFINED GLOBAL OBJECT
/usr/lib/hpux32/unix98.o:
section .sdata PROGBITS AWS 4 8 added to data segment
section .debug_line PROGBITS 26 8 added to nonsegment segment
section .debug_actual PROGBITS 24 8 added to nonsegment segment
section .note NOTE 848 4 added to note segment
ld: Unable to load shared library "/opt/langtools/lib/hpux64/libu2comp.so"
Fatal error.
collect2: ld returned 1 exit status
#
#
# gcc -c scsi_test.c -o scsi_test_relocate.o
gcc: scsi_test.c: linker input file unused because linking not done
#
#

liuyl_it
Frequent Advisor

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

Eventually I found that I had made an embarrassing  low-level mistake!
It seems that the original soruce filename(scsi_test.c) was wrong with some invisible charactors!
Now I just delete this original soruce file and then recreate it, so at last al l right!

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