LinuxQuestions.org - [SOLVED] creating .SO (shared object) file in C code in linux

- Programming (https://www.linuxquestions.org/questions/programming-9/)

- - creating .SO (shared object) file in C code in linux (https://www.linuxquestions.org/questions/programming-9/creating-so-shared-object-file-in-c-code-in-linux-4175464217/)

creating .SO (shared object) file in C code in linux

Quote:

Dear sir,

i have one confusion related to creating the .so file
i am posting the Makefile which creates the .so
It is all ready written but i have some confusions about it.

Code:

all:

        g++ -fPIC -o lib/libcyusb.o -c lib/libcyusb.c

        g++ -shared -Wl,-soname,libcyusb.so -o lib/libcyusb.so.1 lib/libcyusb.o -l usb-1.0 -l rt

        cd lib; ln -sf libcyusb.so.1 libcyusb.so

        rm -f lib/libcyusb.o

clean:

        rm -f lib/libcyusb.so lib/libcyusb.so.1

help:

        @echo  'make          would compile and create the library and create a link'

        @echo  'make clean    would remove the library and the soft link to the library (soname)'

~                                                                                                                                            

~                                                                                                                                            

~

Quote:

my confusions are,
1. Why there is two .so files created "libcyusb.so" "libcyusb.so.1"
what is use of it, what this libcyusb.so.1. is doing
2. what does this command do

Code:

cd lib; ln -sf libcyusb.so.1 libcyusb.so

Quote:

Please help me to understand these things
this file is from the open source utility cyusb for cypress

i want to learn and create my .so also so want to know these things

Thanks & Regards
Rohaan

Recommend you perform an "ls -l" on those two files. I believe you will see that the straight .so file is a symbolic link pointing to the .so.1 file and the so.1 file is the true shared object binary.

This is typical for how .so files are set up, and my assumption has always been that if you have <blah-blah>.so, then you'll always want to have the file in that name. But you can try or cause an upgrade by changing the target of the symbolic link. And then further, the extension on the original binary shared object library file can give you the version, such as .so.1.2.12 means version "1.2.12" if the coder intended it to be that way.

Here's what I'm talking about

Code:

lrwxrwxrwx 1 root root    11 2011-01-11 14:56 libacl.so -> libacl.so.1

lrwxrwxrwx 1 root root    15 2010-11-29 15:06 libacl.so.1 -> libacl.so.1.1.0

-rw-r--r-- 1 root root 30312 2010-02-08 06:09 libacl.so.1.1.0

libacl.so.1.1.0 is the compiled/linked library.
libacl.so.1 is a symbolic link to it
libacl.so is another symbolic link to it.

I don't know why there are two symbolic links, or the true history or why this is done, however this is the first level of explanation for you. And perhaps another responder will explain some more about the full reasons for this.

This method is commonly used to allow applications built against the library to be completely general about the version in use, or to be a s specific as necessary about the library version required. Symbolic links with progressively more specific versioning suffixes allow the library user to craft Makefiles that can accommodate this. Presumably, the '.1' suffix represents the current version of the library package. Subsequent revisions will alter that suffix to reflect the modifications.

--- rod.

The basic idea:

libFoo has two-level version number: major and minor, changing 'minor' means compatible change,
changing 'major' means incompatible change.
The libraries know their 'major' number (cf DT_SONAME), and executables know the 'major' number of the used libraries (cf DT_NEEDED).

Example:

major=3, minor=4.5

Code:

libFoo.so->libFoo.so.3.4.5 -- linker uses this

libFoo.so.3->libFoo.so.3.4.5 -- linked executables use this

libFoo.so.3.4.5 -- this is the actual shared lib

So, what happens when you install version 3.5.7 (major=3, minor=5.7)?
Well, this is a compatible change, the symlinks are updated, so the old programs will use the new shared lib.

Code:

libFoo.so->libFoo.so.3.5.7 -- linker uses this

libFoo.so.3->libFoo.so.3.5.7 -- linked executables use this

libFoo.so.3.5.7 -- this is the new shared lib

And then, you install version 4.1 (major=4, minor=1).
This is a incompatible change, the old programs will still use the old shared lib, only the newly linked programs will use the new lib.

Code:

libFoo.so.3->libFoo.so.3.5.7 -- previously linked executables use this

libFoo.so.3.5.7 -- this is the old shared lib

libFoo.so->libFoo.so.4.1 -- linker uses this

libFoo.so.4->libFoo.so.4.1 -- newly linked executables use this

libFoo.so.4.1 -- this is the new shared lib

Note: Using libtool might be useful, if you follow some good tutorial, because it is not exactly intuitive for beginners.
http://www.gnu.org/software/libtool/...#Using-libtool

Thanks everybody,

I am trying to learn the things...

thanks for support!!!

Thanks & Regards
Rohan

Quote:

Dear everyone,

i have used the "libcyusb.so" to develope my code and now i have created my own .os using

in my makefile

Code:

g++ -c -fPIC        Usb.c -o Usb  -L ../../lib -l cyusb  

        g++ Usb.o -shared -o libUsb.so

Quote:

so can it be possible if use my .so and header file to develop the another application over it??? will it be possble to use my header and .so only or i have to use "libcyusb.so" also???

it is it necessary to have the .so.1 or can i use my .so only???

Thanks & Regards
Rohan

If you're programming for your own purposes and don't intend to release this and have subsequent revisions, then do what you wish; however if you're developing for a customer or for other person's use then please follow the conventions. Many is the time that I felt I was doing a brief, one-time program and would never send out any revisions ... many is the time I've ended up doing not only a revision, but several and instead a much larger project.

# 6 .

http://tldp.org/HOWTO/Program-Librar...libraries.html
>> 3.4. Creating a Shared Library

Example :
libUsb.so.1.0.0 is the "Real name"
libUsb.so.1 is the "so name". Used for run time.
libUsb.so is a link to the version, you want to use for compiling.

I.e. when you update to / create a later version of libUsb,
say libUsb.so.2.0.0, you can decide to compile with this new version,
by changing libUsb.so to point to libUsb.so.2.0.0 .
And : You can have two run time versions, libUsb.so.1 and libUsb.so.2 .

-