About .so and .o files - Unix

This is a discussion on About .so and .o files - Unix ; Hi, I'm relatively new to Unix programming. So kindly empathize. I'm trying to understand the distiction between .so and .o files in Unix. I build the library mylib.so as follows:- code: /* my shared library */ #include void func1() { ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: About .so and .o files

  1. About .so and .o files

    Hi,

    I'm relatively new to Unix programming. So kindly empathize.

    I'm trying to understand the distiction between .so and .o files in
    Unix.

    I build the library mylib.so as follows:-

    code:
    /* my shared library */
    #include

    void func1()
    {
    printf("\n\t mylib: func1()");
    }

    gcc mylib.c -fPIC -shared -o mylib.so

    Then I created an application that uses this library.
    code:
    // myapp
    void main()
    {
    printf("\n\t This is myapp");
    func1();
    }
    and create it as:-

    gcc myapp.c mylib.so -o myapp

    Also, I can generate the .o file of the library mylib.c as:-

    gcc mylib.c -fPIC -shared -o mylib.o

    and build myapp as

    gcc myapp.c mylib.o -o myapp

    Question: What is the difference between these two approaches ?
    Does the second way, where I use the .o file of the library, cause the
    object code to be complied into the myapp executable and in the first
    case, will be shared (and truely acts as a library).

    Would greatly appreciate if someone explains the above and/or other
    issues related to .so and .o files.

    Thanks!

  2. Re: About .so and .o files

    On Aug 7, 3:05*am, Ankur wrote:
    > Hi,
    >
    > I'm relatively new to Unix programming. So kindly empathize.
    >
    > I'm trying to understand the distiction between .so and .o files in
    > Unix.
    >
    > I build the library mylib.so as follows:-
    >
    > code:
    > /* my shared library */
    > #include
    >
    > void func1()
    > {
    > * * * * printf("\n\t mylib: func1()");
    >
    > }
    >
    > gcc mylib.c -fPIC -shared -o mylib.so
    >
    > Then I created an application that uses this library.
    > code:
    > // myapp
    > void main()
    > {
    > * * * * printf("\n\t This is myapp");
    > * * * * func1();}
    >
    > and create it as:-
    >
    > gcc myapp.c mylib.so -o myapp
    >
    > Also, I can generate the .o file of the library mylib.c as:-
    >
    > gcc mylib.c -fPIC -shared -o mylib.o
    >
    > and build myapp as
    >
    > gcc myapp.c mylib.o -o myapp
    >
    > Question: What is the difference between these two approaches ?
    > Does the second way, where I use the .o file of the library, cause the
    > object code to be complied into the myapp executable and in the first
    > case, will be shared (and truely acts as a library).
    >
    > Would greatly appreciate if someone explains the above and/or other
    > issues related to .so and .o files.
    >
    > Thanks!


    Re your questions, you understand it correctly.

    The following is a nice overview of shared libraries (from IBM's
    developerWorks site):
    http://www.ibm.com/developerworks/li.../l-shlibs.html

  3. Re: About .so and .o files

    Ankur writes:

    > I'm trying to understand the distiction between .so and .o files in
    > Unix.
    >
    > I build the library mylib.so as follows:-
    >
    > code:
    > /* my shared library */
    > #include
    >
    > void func1()
    > {
    > printf("\n\t mylib: func1()");
    > }
    >
    > gcc mylib.c -fPIC -shared -o mylib.so
    >
    > Then I created an application that uses this library.
    > code:
    > // myapp
    > void main()
    > {
    > printf("\n\t This is myapp");
    > func1();
    > }

    [#include and int main(void) should really be used here.]
    > and create it as:-
    >
    > gcc myapp.c mylib.so -o myapp
    >
    > Also, I can generate the .o file of the library mylib.c as:-
    >
    > gcc mylib.c -fPIC -shared -o mylib.o
    >
    > and build myapp as
    >
    > gcc myapp.c mylib.o -o myapp
    >
    > Question: What is the difference between these two approaches ?


    None. You just used an odd name, xxx.o, for shared library. To build
    the program without a shared library you need:

    gcc -c mylib.c -fPIC -o mylib.o

    Note the -c (= compile only, don't link) and you don't need -FPIC or
    the -o mylib.o. -c makes xxx.o from xxx.c by default and PIC is only
    important for dynamic linking.

    Then you link:

    gcc myapp.c mylib.o -o myapp

    > Does the second way, where I use the .o file of the library, cause the
    > object code to be complied into the myapp executable and in the first
    > case, will be shared (and truely acts as a library).


    No, simply because you included -shared (and omitted -c).

    > Would greatly appreciate if someone explains the above and/or other
    > issues related to .so and .o files.


    --
    Ben.

  4. Re: About .so and .o files

    On Aug 7, 3:05*am, Ankur wrote:
    > Hi,
    >
    > I'm relatively new to Unix programming. So kindly empathize.
    >
    > I'm trying to understand the distiction between .so and .o files in
    > Unix.
    >
    > I build the library mylib.so as follows:-
    >
    > code:
    > /* my shared library */
    > #include
    >
    > void func1()
    > {
    > * * * * printf("\n\t mylib: func1()");
    >
    > }
    >
    > gcc mylib.c -fPIC -shared -o mylib.so
    >
    > Then I created an application that uses this library.
    > code:
    > // myapp
    > void main()
    > {
    > * * * * printf("\n\t This is myapp");
    > * * * * func1();}
    >
    > and create it as:-
    >
    > gcc myapp.c mylib.so -o myapp
    >
    > Also, I can generate the .o file of the library mylib.c as:-
    >
    > gcc mylib.c -fPIC -shared -o mylib.o
    >
    > and build myapp as
    >
    > gcc myapp.c mylib.o -o myapp
    >
    > Question: What is the difference between these two approaches ?
    > Does the second way, where I use the .o file of the library, cause the
    > object code to be complied into the myapp executable and in the first
    > case, will be shared (and truely acts as a library).
    >
    > Would greatly appreciate if someone explains the above and/or other
    > issues related to .so and .o files.
    >
    > Thanks!


    And, fwiw, another article from IBM's site:
    http://www.ibm.com/developerworks/library/l-shobj/

  5. Re: About .so and .o files

    "shakahshakah@gmail.com" writes:


    >> Also, I can generate the .o file of the library mylib.c as:-
    >>
    >> gcc mylib.c -fPIC -shared -o mylib.o
    >>
    >> and build myapp as
    >>
    >> gcc myapp.c mylib.o -o myapp
    >>
    >> Does the second way, where I use the .o file of the library, cause the
    >> object code to be complied into the myapp executable


    > Re your questions, you understand it correctly.


    Except for the quoted bit, I think.

    --
    Ben.

  6. Re: About .so and .o files

    On Aug 7, 7:16*pm, Ben Bacarisse wrote:
    > "shakahsha...@gmail.com" writes:
    >
    >
    >
    > >> Also, I can generate the .o file of the library mylib.c as:-

    >
    > >> gcc mylib.c -fPIC -shared -o mylib.o

    >
    > >> and build myapp as

    >
    > >> gcc myapp.c mylib.o -o myapp

    >
    > >> Does the second way, where I use the .o file of the library, cause the
    > >> object code to be complied into the myapp executable

    >
    > > Re your questions, you understand it correctly.

    >
    > Except for the quoted bit, I think.
    >
    > --
    > Ben.


    Thanks for your explanation Ben. Apparantly, I kinda figured it out
    myself when I played with the problem a bit...that using -fPIC and -
    shared will create a dynamic library anyway regardless of the
    extension that I specify.
    My idea was to create a static library and thought specifying .o
    extension would create the same, which I can use while building my
    sample application (..as i said i'm a newbie :-)
    I suppose to build a static library one needs to use the "ar" command.
    (Any comments are welcome)

    Thanks shakahshakah@gmail.com, for the useful links.
    Cheers!

+ Reply to Thread