ld(1)

ld(1)

If you do not use +h, the shared library does not have an internal name. The linker does not check whether .sl is a symbolic link. It records the library name that it looks at, if it does not have the internal name.

chatr a.out

...

shared library list: dynamic ./libfoo1.sl

On 32-bit, link a program with libfunc.sl but use the archive version of the C library. Specify the immediate binding mode together with the nonfatal modi®er and allow verbose diagnostics to be displayed:

ld /usr/ccs/lib/crt0.o -B immediate -B nonfatal -B verbose \ program.o -L . -lfunc -a archive -lc

To do this on 64-bit:

ld -B immediate -B nonfatal -B verbose \ program.o -L . -lfunc -a archive -lc

On 32-bit, link a Pascal program:

ld /usr/ccs/lib/crt0.o main.o -lcl -lm -lc

Note that in the above examples, /usr/ccs/lib/crt0.o can be replaced by /opt/langtools/lib/crt0.o.

WARNINGS

ld recognizes several names as having special meanings. The symbol _end is reserved by the linker to refer to the ®rst address beyond the end of the program's address space. Similarly, the symbol _edata refers to the ®rst address beyond the initialized data, and the symbol _etext refers to the ®rst address beyond the program text. The symbols end, edata, and etext are also de®ned by the linker, but only if the program contains a reference to these symbols and does not de®ne them (see end(3C) for details). On 32-bit, the symbol __tdsize is the total thread local storage size required by the program or shared library.

On 64-bit, the linker de®nes a few more symbols. The symbol __TLS_SIZE is the total thread local storage size. The symbol _FPU_STATUS is the initial status of the FPU status register. The symbol __SYSTEM_ID is the largest architecture revision level used by any compilation unit.

The linker treats a user de®nition of any of the symbols listed here as an error.

Through its options, the link editor gives users great ¯exibility. However, those who invoke the linker directly must assume some added responsibilities. Input options should ensure the following properties for programs:

∙When the link editor is called through cc(1), a start-up routine is linked with the user's program. This routine calls exit(2) after execution of the main program. If users call ld directly, they must ensure that the program always calls exit() rather than falling through the end of the entry routine.

∙When linking for use with the symbolic debugger dde, the user must ensure that the program con- tains a routine called main. Also, the user must link in the ®le

/opt/langtools/lib/end.o on 32-bit and /opt/langtools/lib/pa20_64/end.o on 64-bit as the last ®le named on the command line.

There is no guarantee that the linker will pick up ®les from archive libraries and include them in the ®nal program in the same relative order that they occur within the library.

The linker emits warnings where ever it detects any compatibility issues. Among other things, these issues include architectural ones, as well as functionality that may change over time. Some of these include:

∙Linking a PA 2.0 object ®le, which will not run on a PA 1.x system.

∙Incremental loading with the -Aoption.

∙Procedure call parameter and return type checking, including the -Coption.

∙Symbols with the same name but different types, such as CODE and DATA.

∙Checking of unsatis®ed symbols by the linker, which sometimes skips certain object ®les from an archived library. This warning is only given if the -voption is also provided.

HP-UX Release 11i: December 2000

− 15 −

Section 1−437

l