What is Dynamically linked library?

QNX Newsgroups (Archives) qdn.public.qnxrtp.newuser
1

I have seen some article of share library? But I still have some question.

1.What is Dynamically linked library? In Qnx it is all named as *.so?

2.When I use c library (libc.so) function such as printf(…).We don’t use
dlopen()
or dlclose() function to load the library to memory.But we can use the
printf() function
at once.Why? So I think that The libc.so seems not Statically linked lib,I
think that it
seems not Dynamically linked lib either.
So what style-lib the libc.so is?

3.Where does the Dynamically linked library used in normally?

4.What style-lib the libshared.so is?
qcc -Vgcc_ntox86 -shared -c shared.c
qcc -Vgcc_ntox86 -shared -o libshared.so shared.o

Any help will be appreciated.

2

“zhz_zhang” <zhz_zhang26@sina.com> wrote in message
news:aqvmdm$g5o$1@inn.qnx.com…

I have seen some article of share library? But I still have some question.

1.What is Dynamically linked library? In Qnx it is all named as *.so?

This is a library which has PIC (position independent code) in it which can
be mapped into multiple processes’ address space. The OS loads the library
into memory and then every process can use it after establishing the
addresses of the functions within the lib. This is done by the dynamic
loader.

2.When I use c library (libc.so) function such as printf(…).We don’t use
dlopen()
or dlclose() function to load the library to memory.But we can use the
printf() function
at once.Why? So I think that The libc.so seems not Statically linked
lib,I
think that it
seems not Dynamically linked lib either.
So what style-lib the libc.so is?

3.Where does the Dynamically linked library used in normally?

The most common usage of shared libs is just as you describe with libc.
When you create your application, it is linked against the shared object and
function call stubs are created which are capable of calling out to an
arbitrary address. Take a look at this (
http://www.linuxjournal.com/article.php?sid=1060 ) article which has a bit
of explanation of how the elf format works. The sections you’re interested
in are plt (procedure linkage table) and got (global offset table).

4.What style-lib the libshared.so is?
qcc -Vgcc_ntox86 -shared -c shared.c
qcc -Vgcc_ntox86 -shared -o libshared.so shared.o

This is a shared library which can be used in at least two ways. You could
link an application at compile time:

qcc -o myapp myapp.c -L. -lshared (-L to add a library search path, -l
to link against lib.so)

or use dlopen() to load the lib at run time.

In both cases, the dynamic loader will load libshared.so and set up the got
with appropriate addresses, the only difference being whether it happens at
program start (we don’t use lazy linking - see above article) or later.

cheers,

Kris

3

Kris Warkentin <kewarken@qnx.com> wrote in message
news:ar0fro$19k$1@nntp.qnx.com…

“zhz_zhang” <> zhz_zhang26@sina.com> > wrote in message
news:aqvmdm$g5o$> 1@inn.qnx.com> …

2.When I use c library (libc.so) function such as printf(…).We don’t
use dlopen()
or dlclose() function to load the library to memory.But we can use the
printf() function
at once.Why? So I think that The libc.so seems not Statically linked
lib,I think that it
seems not Dynamically linked lib either.
So what style-lib the libc.so is?

libc of cause is Dynamic linked lib. The fact you didn’t call dlopen() just
means, somebody
loaded it for you (before your main() get called).

When you linking your program, you (or the linker) already decided it will
need Dynamic
Linked libc.so, the information is stored in your binary, and when you
asking to run
your program, somebody (the loader) deicded to load that for you.

objdump -x on your binary, you would see “NEEDED” lines, which telling
loader what
THIS binary needed before it’s main() get called.

3.Where does the Dynamically linked library used in normally?

The most common usage of shared libs is just as you describe with libc.

Code sharing. Since almost every application need libc, (yeah, they may not
need
the whole libc but …) it make sense to have one copy of libc exist in
memroy, everybody
call into it, then every application have their own copy of (partial) libc.

Dynamic processing (plug in): You wait until seeing the incomming data, and
decided
it is, let’s say, a mpeg2 stream, then you dlopen() a mpeg2-codec.so, pass
the stream
to it…

-xtang

4

Now I have understand more about Dynamically linked library.

Assume that I have a shared lib named “shared.so”.

If I want to directly load the Dynamically linked library,just use "qcc -o
myapp myapp.c -L. -lshared ".When the myapp running ,the Dynamically linked
library is loaded automatically.

If I use dlopen() function .The Dynamically linked library is loaded when
you call dlopen().So whether the library is load rely on when you call
dlopen() function in myapp.c.

It seems that When you want to use many function in shared lib,directly
use (qcc …-lshared) link should be very convenient.

If I have create a Dynamically linked library named shared.so.How to set up
it?
What I do is that:

Assume The real position of shared.so is in /mylib/shared.so.
Just setup a link file “shared.so” into /lib or /usr/lib directory to the
real position of the shared.so .
cd /lib
ln -s /mylib/shared.so shared.so.
Then use" qcc -o myapp myapp.c -lshared " or
dlopen(“coolobj1.so”,RTLD_GLOBAL) to load them.

Is this all right?

5

Sorry .The call of dlopen should be
dlopen(“shared.so”,RTLD_GLOBAL),not coolobj1.so.

Forgive my incaution.

“zhz_zhang” <zhz_zhang26@sina.com> wrote in message
news:ar1ihh$m60$1@inn.qnx.com…

Now I have understand more about Dynamically linked library.

Assume that I have a shared lib named “shared.so”.

If I want to directly load the Dynamically linked library,just use
"qcc -o
myapp myapp.c -L. -lshared ".When the myapp running ,the Dynamically
linked
library is loaded automatically.

If I use dlopen() function .The Dynamically linked library is loaded
when
you call dlopen().So whether the library is load rely on when you call
dlopen() function in myapp.c.

It seems that When you want to use many function in shared lib,directly
use (qcc …-lshared) link should be very convenient.

If I have create a Dynamically linked library named shared.so.How to set
up
it?
What I do is that:

Assume The real position of shared.so is in /mylib/shared.so.
Just setup a link file “shared.so” into /lib or /usr/lib directory to the
real position of the shared.so .
cd /lib
ln -s /mylib/shared.so shared.so.
Then use" qcc -o myapp myapp.c -lshared " or
dlopen(“coolobj1.so”,RTLD_GLOBAL) to load them.

Is this all right?

6

“zhz_zhang” <zhz_zhang26@sina.com> wrote in message
news:ar1ihh$m60$1@inn.qnx.com…

Assume The real position of shared.so is in /mylib/shared.so.
Just setup a link file “shared.so” into /lib or /usr/lib directory to the
real position of the shared.so .
cd /lib
ln -s /mylib/shared.so shared.so.
Then use" qcc -o myapp myapp.c -lshared " or
dlopen(“coolobj1.so”,RTLD_GLOBAL) to load them.

This is a perfectly reasonable way of doing it although the link is not
strictly necessary unless you have some good reason for wanting to keep them
separate. Otherwise, you could just put libshared.so directly into /lib or
/usr/lib. As an alternative, you could just put your shared lib in /mylib
and then compile as “qcc -o myapp myapp.c -L/mylib -lshared”. Then all you
would need to do is “export LD_LIBRARY_PATH=/mylib” to make sure that the
loader searches that directory as well.

cheers,

Kris

7

kewarken@qnx.com sed in <ar1m7b$oqv$1@nntp.qnx.com>

and then compile as “qcc -o myapp myapp.c -L/mylib -lshared”. Then all you
would need to do is “export LD_LIBRARY_PATH=/mylib” to make sure that the
loader searches that directory as well.

Oooo, don’t do this, avoid LD_LIBRARY_PATH whenever you can.
Use
LD_RUN_PATH=/mylib qcc -o myapp myapp.c -L/mylib -lshared


(If you’re stuck on QNX 6.1, yes using LD_LIBRARY_PATH is the only option
as the loader bug ignored RPATH)

kabe

8

<kabe@sra-tohoku.co.jp> wrote in message news:ar34o1$epm$1@inn.qnx.com…

kewarken@qnx.com > sed in <ar1m7b$oqv$> 1@nntp.qnx.com

and then compile as “qcc -o myapp myapp.c -L/mylib -lshared”. Then all
you
would need to do is “export LD_LIBRARY_PATH=/mylib” to make sure that
the
loader searches that directory as well.

Oooo, don’t do this, avoid LD_LIBRARY_PATH whenever you can.
Use
LD_RUN_PATH=/mylib qcc -o myapp myapp.c -L/mylib -lshared


(If you’re stuck on QNX 6.1, yes using LD_LIBRARY_PATH is the only option
as the loader bug ignored RPATH)

Yes, of course. This is helpful if you want your binary to know where its
shared libs are. :wink: I had forgotten about that one. Thanks Kabe.

cheers,

Kris