Unfortunately I am a newbie to both Linux and CodeLite, but CodeLite has made the shift to Linux (so far) much less painful so I cannot complain.
The issue I am having maybe more a Linux issue than a CodeLite issue but my ignorance is too great to know.
I am trying to create two dynamically loaded libraries. The source of both is straight C code, but one will be loaded by java and the other by C++ based executables.
In Linux, such a beast has three components; libMyLibrary.so, libMyLibrary.so.1, libMyLibrary.so.1.0.0
Going through the process of configuring the project generates the libMyLibrary.so file by default (at least the CodeLite version for Fedora 15 does).
How do I generate the other two files or should I configure the default 'so' name to 'so.x.y.z' where the x.y.z is the version number and use some other tool to generate the other two 'libraries'?
Hopefully, once I get these three files generated I can copy them to their expected location /usr/lib or something like that and be able to use them in those programs that need them.
Building shared libraries on Linux
-
- CodeLite Enthusiast
- Posts: 19
- Joined: Sat Jun 04, 2011 6:22 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
-
- CodeLite Enthusiast
- Posts: 37
- Joined: Fri Feb 05, 2010 10:57 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Building shared libraries on Linux
1. Use the linker flag "-soname=libNAME.so.1" to set the shared object name.
2. As su: copy the library to /usr/lib/libNAME.so.1.x.x
3. As su: run ldconfig which creates the links /usr/lib/libNAME.so.1
2. As su: copy the library to /usr/lib/libNAME.so.1.x.x
3. As su: run ldconfig which creates the links /usr/lib/libNAME.so.1
-
- CodeLite Enthusiast
- Posts: 19
- Joined: Sat Jun 04, 2011 6:22 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Building shared libraries on Linux
Josee,
Thanks for the info; that sounds quite straight forward.
However, which of these three libraries does CodeLite generate when the project type is set to Linux-based dynamic library? The CodeLite default name in that case is lib$(ProjectName).so. So I guess that I should add the versioning information to this such that is becomes lib$(ProjectName).so.x.y.z and then one can apply the other operations you mention in your post.
Though I am trying to get it clear in my head what the difference between these three versions of the dynamic library ['links' versus real', etc.] are (thanks for the web!). However, on my system all three (in each set) have exactly the same size. Just seems weird.
In the spirit of CodeLite, this sequence of command line executions would be configured in the post-build event. Well, at least that's what I believe the post-build configuration is for. So in the end, I want to take the CodeLite generated result and configure the post-build event to operate on this result in the way you mention and I should have a dynamic library ready for loading!
Thanks for the info; that sounds quite straight forward.
However, which of these three libraries does CodeLite generate when the project type is set to Linux-based dynamic library? The CodeLite default name in that case is lib$(ProjectName).so. So I guess that I should add the versioning information to this such that is becomes lib$(ProjectName).so.x.y.z and then one can apply the other operations you mention in your post.
Though I am trying to get it clear in my head what the difference between these three versions of the dynamic library ['links' versus real', etc.] are (thanks for the web!). However, on my system all three (in each set) have exactly the same size. Just seems weird.
In the spirit of CodeLite, this sequence of command line executions would be configured in the post-build event. Well, at least that's what I believe the post-build configuration is for. So in the end, I want to take the CodeLite generated result and configure the post-build event to operate on this result in the way you mention and I should have a dynamic library ready for loading!
-
- CodeLite Enthusiast
- Posts: 37
- Joined: Fri Feb 05, 2010 10:57 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Building shared libraries on Linux
( I am using external Makefiles (managed by genmake) so I do not use many of CodeLite settings. )
But either name your shared library project "libNAME" or set the output name to "lib$(ProjectName).so".
( The use of suffixes is to differentiate between incomaptible main version ".so.1", ".so.2".
The second suffix is to differentiate between the compatible features ".so.1.2", ".so.1.3".
The third suffix is to differentiate between the libs with same features / compatible interface
but different patch level. )
To use your shared library it is not necessary to have all these different versions and to copy it to /usr/lib.
A simple libNAME.so suffices. To use a shared library from another project it suffices to set either
the environment variable "LD_LIBRARY_PATH=/path_to_your_lib:..." or to set linker option "-rpath=/path_to_your_lib".
See "man ld.so" for infos about LD_LIBRARY_PATH and "man ld" for infos about "-rpath"
(Use "/search_string" command in man to search for the correct pos and command "n" or "N" to search next or previous).
Use "/usr/lib" only if you want to install your project permanently.
But either name your shared library project "libNAME" or set the output name to "lib$(ProjectName).so".
( The use of suffixes is to differentiate between incomaptible main version ".so.1", ".so.2".
The second suffix is to differentiate between the compatible features ".so.1.2", ".so.1.3".
The third suffix is to differentiate between the libs with same features / compatible interface
but different patch level. )
To use your shared library it is not necessary to have all these different versions and to copy it to /usr/lib.
A simple libNAME.so suffices. To use a shared library from another project it suffices to set either
the environment variable "LD_LIBRARY_PATH=/path_to_your_lib:..." or to set linker option "-rpath=/path_to_your_lib".
See "man ld.so" for infos about LD_LIBRARY_PATH and "man ld" for infos about "-rpath"
(Use "/search_string" command in man to search for the correct pos and command "n" or "N" to search next or previous).
Use "/usr/lib" only if you want to install your project permanently.