Using 64-bit Mode Linker Options

This section introduces 64-bit-only linker options.

Using the 64-bit Mode Linker with +compat or +std

In the HP-UX 11.0 release, the linker toolset supports extended features for linking in 64-bit mode. Since compatibility with the previous linker toolset is a high priority, the 64-bit linker uses much of the old behavior in the new toolset. The 64-bit mode linker includes two options to allow you to instruct the linker to link in one of two modes:

Compatibility mode, with the +compat option, to create a link and operation in 32-bit style. Because of some object file format restrictions, the mode is not completely compatible with the style of the 32-bit linker.
Standard mode, with the +std option, set by default in 64-bit mode, to create a link and load operation in 64-bit style. This mode uses the new behaviors and features of the 64-bit linker.

Using the Linker with +compat for Compatibility Mode

The +compat option instructs the linker to do a 32-bit-style link.

When you use the +compat option, the linker:

Uses 32-bit style shared library internal name processing.
Lists all dependent shared libraries in a DT_HP_NEEDED entry the dynamic table using the 32 bit-style shared library naming conventions. These dependent libraries are recorded as compatibility mode libraries even if they are really created as standard mode dependent libraries.
If an error occurs during the link, the linker creates an a.out without the executable permission bits set.
Does not use embedded paths at link time to find dependent libraries.
Considers the order of ld +b and +s.
- +b first means dld looks at the RPATH first when searching for dependent shared libraries.
  To get the default RPATH, you must specify ld +b. This instructs the linker to construct a default RPATH consisting of the -L directories and LPATH.
- +s first means the dynamic loader looks at the SHLIB_PATH environment variable first when searching for dependent shared libraries.
  You must specify ld +s to force the dynamic loader to use SHLIB_PATH to search for shared libraries at runtime.

At runtime, the dynamic loader does a 32-bit style load for all compatibility mode dependent shared libraries. The dynamic loader:

Does dynamic path searching for compatibility-mode dependent shared libraries that have the dynamic path selected (set in the DT_HP_NEEDED entry if the shared library was specified with -l).
Uses SHLIB_PATH only if you specify ld +s (or chatr +s) for compatibility-mode shared libraries.
Allows RPATH inheritance from ancestors to children when searching for dependent compatibility-mode shared libraries specified with ld -l. This is only allowed in an a.out that was linked with +compat. If the a.out was linked +std, no library (even a compatibility mode shared library) uses embedded RPATH inheritance.
Allows dynamic path searching on shared libraries loaded by shl_load routines, if the DYNAMIC_FLAG is passed to shl_load().
Does a depth-first search of all compatibility-mode dependent libraries.
Looks at RPATH or SHLIB_PATH first, depending on the ld +b/+s ordering for all ld -l dependent shared libraries. The dynamic loader looks at whichever has second precedence next, and then looks for the shared library as specified in the dynamic load entry.
Looks for the dynamic table entry as if the dynamic path bit is not set.

Using the 64-bit Linker with +std for Standard Mode

The +std option instructs the linker to do a standard mode 64-bit style link. This is currently the default in 64-bit mode.

This default may change in future releases.

When you use +std, the linker:

Assumes -dynamic was passed to ld. The linker looks for shared libraries first. The output executable is a shared executable.
All dependent shared libraries are output in the dynamic table in a DT_NEEDED entry. These dependent shared libraries are recorded as standard mode shared libraries.
ld +b and +s ordering is ignored. ld +s is on by default.
If an error occurs during the link, the linker does not generate an a.out file.
Uses de facto standard internal name processing for dependent shared libraries.
Uses embedded RPATHs at link time to find dependent shared libraries.
If you do not specify ld +b, the linker uses a default RPATH consisting of the -L directories, LPATH, and the default directories /usr/lib/pa20_64:/usr/ccs/lib/pa20_64.

At runtime, the dynamic loader does a 64-bit-style load for all standard mode dependent shared libraries. The dynamic loader:

Does dynamic path searching only for standard-mode shared libraries in the DT_NEEDED entry of the dynamic table which do not contain a path. For those standard-mode dynamic libraries that contain paths, dld looks for the library as specified.
Looks for the shared library as specified in the DT_NEEDED dynamic table entry if it contains a path.
Looks at LD_LIBRARY_PATH and SHLIB_PATH environment variables at runtime by default when doing dynamic path searching for standard-mode shared libraries.
Does not allow RPATH inheritance from ancestors to children (only allowed from parent to child).
Does a breadth-first search for all standard-mode dependent shared libraries.
Looks at the environment variables first, followed by RPATH, and the default directories by default when doing dynamic path searching for standard-mode dependentshared libraries.

Linking Shared Libraries with -dynamic

Use the -dynamic option to instruct the linker to look for shared libraries first and then archive libraries. The linker outputs a dynamically linked executable.

This option is on by default in standard mode.

In the following example, the linker only looks for shared libraries:

$ld main.o -dynamic -L. -lbar -lc

If you specified an archive library, the linker links it in, but the resulting executable is still a dynamically linked executable. This is true even if the linker finds no shared libraries at link time.

Linking Archived Libraries with -noshared

Use the -noshared option if you need to link with all archive libraries. The linker outputs a statically bound executable.




	NOTE: You cannot link in shared libraries if you specify this option.

In the following example, the linker only looks for /usr/lib/pa20_64/libfoo.a and /usr/lib/pa20_64/libc.a:

ld crt0.o main.o -noshared -L. -lfoo -lc

If you specify a shared library with this option, the linker emits an error message.

ld: The shared library "libbar.sl" cannot be processed in a static link.
Fatal error.

Controlling Archive Library Loading with +[no]forceload

Use the +[no]forceload option to control how the linker loads object files from an archived library. +forceload instructs the linker to load all object files from an archive library. +noforceload tells the linker to only load those modules from an archive library that is needed. The mode you select, either by default or explicitly, remains on until you change it.

+noforceload is the default on both 32-bit and 64-bit modes.

In the following example, main() references foo(), which is a module in mylib.a. foo() doesn't reference any other module in mylib.a and libc.a. If mylib.a contains foo.o and bar.o, then only foo.o is linked in.

ld crt0.o main.o +vtype libraries mylib.a -lc

...
Selecting liba.a[foo.o] to resolve foo

ld crt0.o main.o +forceload mylib.a -lc +vtype libraries

...
Selecting liba.a[foo.o] to forcibly load
Selecting liba.a[bar.o] to forcibly load

Flagging Unsatisfied Symbols with +[no]allowunsats

Use the +allowunsats option to instruct the linker to not flag unsatisfied symbols at link time. This is the default for relocatable (-r) and shared library builds (-b), and is the default behavior in 32-bit mode.

Use the +noallowunsat option to instruct the linker to flag as an error any unsatisfied symbol in the resulting output file. The linker still creates a.out, but the file does not have any execute permission bits set. This is the default for program files (same behavior as in 32-bit mode).

For example, where main() references functions foo() and bar(). bar() resides in libbar.sl. foo() resides in libfoo.sl

ld main.o +allowunsats -L. -lbar -lc

ld: (warning) Unsatisfied symbol "foo".
1 warning.

+allowunsats still causes the linker to emit a warning message and output a.out. If you do not specify the option and the linker finds an unsatisfied symbol, the linker emits an error message and an unexecutable a.out only if linking with +compat set.

ld main.o -L. -lbar -lc

ld: Unsatisfied symbol "foo".
1 error.

Hiding Symbols from export with +hideallsymbols

Use the +hideallsymbols option to hide all symbols to prevent the linker from exporting them in a shared link.

In the following example, main() exports func() and test(). Using +hideallsymbols, the linker does not export these two routines in the a.out.

ld main.o +hideallsymbols -L. -lfoo -lc

elfdump -t a.out

a.out:
 
...
.symtab
 
index 	Type 	Bind 	Other 	Sect	Value			Size	Name1 	FUNC 	LOCL 	0	0xb 	0x4000000000001104 			0					test...10	FUNC	LOCL	0	0xb	0x4000000000001200			0							func

Changing Mapfiles with -k and +nodefaultmap

The linker automatically maps sections from input object files onto output segments in executable files. These options to the ld command allow you to change the linker's default mapping.

Use the -k filename option to provide a memory map. The linker uses the file specified by filename as the output file memory map.

The +nodefaultmap option used with -k option prevents the linker from concatenating the default memory map to the map provided by filename. If you specify +nodefaultmap, the linker does not append the default mapfile to your mapfile. If you do not specify +nodefaultmap with -k, the linker appends the output file to the default mapfile.




	NOTE: In most cases, the linker produces a correct executable without the use of the mapfile option. The mapfile option is an advanced feature of the linker toolset intended for systems programming use, not application programming use. When using the mapfile option, you can create executable files that do not execute.

For more information on mapfiles and examples using these options, see Appendix A “Using Mapfiles”.

Ignoring Dynamic Path Environment Variables with +noenvvar

Use the +noenvvar to instruct the dynamic loader not to look at the environment variables relating to dynamic path searching at runtime. It ignores LD_LIBRARY_PATH and SHLIB_PATH environment variables. This option is on by default in with ld +compat. It is off by default with ld +std.

For example, if libbar.sl has dependent library libfee.sl that is i ./ at link time, but is moved to /tmp by runtime:

ld main.o -L. -lbar -lc
export LD_LIBRARY_PATH=/tmp
mv libbar.sl /tmp
a.out
	called bar() 
	called fee()
mv /tmp/libbar.sl ./
ld main.o +noenvvar -L. -lbar -lc
mv libbar.sl /tmp
a.out
	dld.sl: Unable to find library "libbar.sl"

Linking in 64-bit Mode with +std

Use the +std option to instructs the linker to do a 64-bit mode link. This is the default mode. For more information, see “Using the 64-bit Mode Linker with +compat or +std”.

Linking in 32-bit Mode Style with +compat

Use the +compat option to instruct the linker to do a 32-bit mode style link. For more information, see “Using the 64-bit Mode Linker with +compat or +std”.

Controlling Output from the Unwind Table with +stripwind

Use the +stripunwind option to suppress output of the unwind table.

ld -b foo.o -o libfoo.sl +stripunwind
elfdump -U libfoo.sl

libfoo.sl:

Selecting Verbose Output with +vtype

Use the +vtype option to get verbose output about specified elements of the link operation. The following values specify the type:

Parameter Description

files

Dump information about each object file loaded.

ld main.o +vtype files -L. -lfile1 -lfile2 -lc
Loading main.o:
Loading ./libfile1.sl:
Loading ./libfile2.sl:
Loading /usr/lib/pa20_64/libc.2:
Loading /usr/lib/pa20_64/libdl.1:

libraries

Dump information about libraries searched.

ld main.o +vtype libraries -L. -lfile1 -lfile2 -lc
Searching /usr/lib/pa20_64/libc.a:
Selecting /usr/lib/pa20_64/libc.a[printf.o] to resolve printf
Selecting /usr/lib/pa20_64/libc.a[data.o] to resolve __iob
...

sections

Dump information about each section added to the output file.

ld main.o +vtype sections -L. -lfile1 -lfile2 -lc
main.o:
section .text PROG_BITS AX 116 8 added to text segment
section .PARISC.unwind UNWIND 16 4 added to text segment
section .data PROG_BITS AW 96 8 added to data segment

symbols

Dump information about global symbols referenced/defined from/in the input files.

ld main.o +vtype symbols -L. -lfile1 -lfile2 -lc
main.o:
	main is DEFINED GLOBAL FUNC
	printf is UNDEF GLOBAL FUNC
	lib1_func is UNDEF GLOBAL FUNC
	lib2_func is UNDEF GLOBAL FUNC
./libfile1.s:
	printf is UNDEF GLOBAL FUNC
	_DYNAMIC is DEFINED GLOBAL OBJECT
	lib1_func is DEFINED GLOBAL FUNC
	...

all

Dump all of the above. Same as -v.

ld main.o +vtype all -L. -lfile1 -lfile2 -lc
Loading main.o:
main.o:
	main is DEFINED GLOBAL FUNC
	printf is UNDEF GLOBAL FUNC
	lib1_func is UNDEF GLOBAL FUNC
	lib2_func is UNDEF GLOBAL FUNC
main.o:section .text PROG_BITS AX 116 8 added to text segment
section .PARISC.unwind UNWIND 16 4 added to text segment
section .data PROG_BITS AW 96 8 added to data segment
Loading ./libfile1.sl:
./libfile1.sl:
...

Linking with the 64-bit crt0.o Startup File

In 32-bit mode, you must always include crt0.o on the link line.

In 64-bit mode, you must include crt0.o on the link line for all fully archive links (ld -noshared) and in compatibility mode (+compat). You do not need to include the crt0.o startup file on the ld command line for shared bound links. In 64-bit mode, the dynamic loader, dld.sl, does some of the startup duties previously done by crt0.o.

See “The crt0.o Startup File”, and crt0(3) manual page for more information.