is stdio.h is a shared library

[deepak]

Hi,

Is this stdio.h is a shared library. If not what are the shared
libraries a normal programmer uses?

Thanks,
Deepak

[David Schwartz]

On Aug 14, 12:31 am, deepak <deepakpj...@gmail.com> wrote:

> Is this stdio.h is a shared library.

No, it's a header file.

> If not what are the shared
> libraries a normal programmer uses?

Among others, libc.so, which contains the C standard library which
includes the implementation of most of the functions prototyped in the
stdio.h header file. You can find out what shared libraries any Linux
executable (almost) uses by using the 'ldd' command. For example
(Fedora 11, x86_64):

$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff7e72e000)
librt.so.1 => /lib64/librt.so.1 (0x0000003019800000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003019400000)
libcap.so.2 => /lib64/libcap.so.2 (0x000000301d400000)
libacl.so.1 => /lib64/libacl.so.1 (0x0000003022a00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003018000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003018c00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003017c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003018400000)
libattr.so.1 => /lib64/libattr.so.1 (0x000000301c800000

DS

[Loïc Domaigné]

Hi.

> Is this stdio.h is a shared library. If not what are the shared
> libraries a normal programmer uses?

stdio.h is a header file, not a shared library... If you mean: where
are the things defined in stdio are located, then: it's in the shared
library libc.so (exact location depends on the distro).

You can find out on which shared lib a binary depends using the ldd
command.

Cheers,
Loïc
--
My Blog: http://www.domaigne.com/blog

“The most amazing achievement of the computer software industry is its
continuing cancellation of the steady and staggering gains made by the
computer hardware industry.” -- Henry Petroski

[Deepak]

Could you tell how it will be mapped to a running program. I'm not
able to map it properly.

This is what my assumption is. If there is a call happens to a
function declared in stdio.h,
at runtime Operating system resolves the address using some kind of
symbol table.
Is it this way they are resolving it?

Please correct me.

Thanks,
Deepak

[Thomas Zimmermann]

Hi

> This is what my assumption is. If there is a call happens to a function
> declared in stdio.h,
> at runtime Operating system resolves the address using some kind of
> symbol table.
> Is it this way they are resolving it?

It depends. In a system with static linking every call is resolved by the
linker during the final compilation step. The library becomes a part of
the application binary.

In a system with dynamic linking, the application only contains
references to the library's functions. A reference is resolved when the
application is loaded into memory or when a referenced function is first
called.

You should read the two texts I pointed you to in the other thread. All
this is explained there in detail.

Thomas

[Deepak]

Hi Thomas,

Yes. I'm going through the Linker and Loader book and now struggling
in object files chapter. But it's really good and I'm able to connect
lot
of things which I was not clear.

Thanks a lot,
Deepak

[Rainer Weikusat]

Deepak <deepa...@gmail.com> writes:
> On Aug 14, 1:32�pm, David Schwartz <dav...@webmaster.com> wrote:
>> On Aug 14, 12:31�am, deepak <deepakpj...@gmail.com> wrote:
>>
>> > Is this stdio.h is a shared library.
>>
>> No, it's a header file.
>>
>> > If not what are the shared
>> > libraries a normal programmer uses?
>>
>> Among others, libc.so, which contains the C standard library which
>> includes the implementation of most of the functions prototyped in the
>> stdio.h header file.

[...]

> Could you tell how it will be mapped to a running program. I'm not
> able to map it properly.
>
> This is what my assumption is. If there is a call happens to a
> function declared in stdio.h, at runtime Operating system resolves
> the address using some kind of symbol table. Is it this way they are
> resolving it?

A simplified description would be: The way a call to a subroutine in
another shared object works is that a jump table exists for all such
entry points and the call in the program source code is basically
translated to 'jump to address contained in table[n]' where 'n' is the
index of the slot associated with the supposed-to-be-invoked
subroutine. Initially, all table slots contain the address of a
subroutine being part of the runtime linker and this subroutine is
supposed to load the shared object, determine the real address of the
'target subroutine' and change the value in the table slot
accordingly.

[Joe Pfeiffer]

deepak <deepa...@gmail.com> writes:
>
> Is this stdio.h is a shared library. If not what are the shared
> libraries a normal programmer uses?

a .h file is a little bit of source code -- it isn't a library at all.

The functions which have prototypes in <stdio.h> are in libc, which is a
shared library.
--
Klingon programs don't have parameters. They have arguments and win
them (Walter Bushell)

[Deepak]

On Aug 14, 6:15 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

Even without including stdio.h file, program knows the prototype.
So how program is learning it?

Thanks,
Deepak

[Rainer Weikusat]

Deepak <deepa...@gmail.com> writes:
> On Aug 14, 6:15�pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>> deepak <deepakpj...@gmail.com> writes:
>>
>> > Is this stdio.h is a shared library. If not what are the shared
>> > libraries a normal programmer uses?
>>
>> a .h file is a little bit of source code -- it isn't a library at all.
>>
>> The functions which have prototypes in <stdio.h> are in libc, which is a
>> shared library.

[...]

> Even without including stdio.h file, program knows the prototype.

It doesn't. Historically, calls to undeclared functions were
translated based on the assumptions that the linkage of the identifier
should be external, that the function will return an int and take
exactly the arguments passed to it, ie without needing further type
conversions.

This is no longer valid C as of C99 but still supported.