verma wrote:
>> oxpoly 553. mv CRLE/config CRLE/ld.config.test
>> oxpoly 554. LD_DEBUG=basic CRLE/test
>> 08680:
>> 08680: configuration file=/home/rie/verma/CRLE/ld.config.test: [
>> DIRECTORY-CONFIG OBJECT-ALTERNATIVES MEMORY-RESERVATION >FILTER-ASSOCIATIONS
>> ]
>
>> Now things start to work:
>
> 1. Why you are renaming this file config to as ld.config.test why not using
> LD_CONFIG=config
I told you in my posting that you could do either:
>> oxpoly 549. ldd -e LD_CONFIG=CRLE/config CRLE/test
>> libc.so.1 => /home/rie/verma/CRLE/libc.so.1 (alternate)
>> libm.so.2 => /home/rie/verma/CRLE/libm.so.2 (alternate)
>> /home/rie/verma/CRLE/libc_psr.so.1 (alternate)
The -e option to ldd is simply a means of establishing an
environment variable to ld.so.1.
> When I also rename my config file as ld.config.test this works fine.
> I think this is directly used by ld.so.1
> This is not documented anywhere in Sun?Doc(Linker loader guide etc)
It is documented in the crle(1) man page:
By default, the runtime linker attempts to read the confi-
guration file /var/ld/ld.config for each 32-bit application
processesed. /var/ld/64/ld.config is read for each 64-bit
application. When processing an alternative application, the
runtime linker uses a $ORIGIN/ld.config.app-name configura-
tion file if present.
Nope, there's not much about crle in the Linker and Libraries guide.
> 2. CRLE internally used dldump(3DL) for dumping the objects.
Yes is does.
> so I have one question regarding this, crle depends on libc.so.1
> and librtld.so.1 on libc.so.1 then how these libc.so.1 dependencies
> loaded in memory ie one instance for crle and other for librtld.so.1
> or only one instance is loaded and used by crle and librtld.so.1
crle(1) is a front end that executes the object in a similar manner
as ldd(1). The use of librtld, and the associated dldump() are
functions of ld.so.1, which occur on an alternative link-map list
within ld.so.1.
--
Rod
