[SOLVED] creating .SO (shared object) file in C code in linux
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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
Last edited by rohaanembedded; 05-31-2013 at 07:19 AM.
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.
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.
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
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???
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.
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 .
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.