Like in Windows systems, I want to make dynamic link libraries that can be reused without rebuilding binaries. If I make a change to a library and the header is unaltered, I dont have to rebuild the entire project. This is the simplest way of patching/updating.

On Linux I have found that my libraries from the ar program are being directly injected into the binary. I have to rebuild any binary that uses the slightly altered library.

First, I build an object with complex arguments. Second I call ar with its arguments on the object. Third, i build the binary. All seemed satsfactory, even trying debug and release versions. However, this is confusing from the size of the binary to viewing its contents, to getting new segment errors. Im sure im missing something.

Has anyone tried building a library that is truly dynamic like Windows?

I guess im getting what I deserve.

Yes, shared libraries are quite common in Unix. For example, try this:
every 'so'-file you see is a 'shared object' (or DLL)

ar builds .a libraries in Linux, which correspond to .lib in Windows.

You want .so libraries in Linux, which correspond to .dll in Windows.

If you are coding C and/or C++, then the easiest way to create the .so file is with appropriate options to GCC (which will then invoke the linker for you to create the .so). Alternately, you could create .o files and invoke the linker yourself. But you still need to change your GCC options, because a .o intended for use in a .so is different from an ordinary .o

Also be aware of another Linux vs. Windows difference. When you create a .DLL in Windows, you also create a stub .lib and that stub lib is used when linking executables that use the .DLL. When you create a .so, there is no stub .a; The .so itself is used in linking the final executable.

Depending on how you set things up, an automated build system may think the final executable needs to be relinked every time the .so is relinked. But if you changed only implementation, not interface within the .so, an executable linked against an older version of the .so will work with a newer version.

Dynamic / shared libraries :

. http://tldp.org/HOWTO/Program-Librar...libraries.html

1 members found this post helpful.

Quite a lot of that just applies to those creating .so files for inclusion in packages in distributions and/or for general purpose utilities to be used by multiple other projects.

All of that seems to be mixed there with the basic things you **need** to do in order to build/use a .so at all.

I'm just worried all that would make a beginner think .so files in Linux are far more complicated than DLL files in Windows, and so might give up on the idea entirely. In fact building and using .so files in Linux is slightly simpler than DLL in Windows.

If you are building a piece of what you hope to be a popular open source project, then you do need to do all that stuff the specified way, rather than some easier way that works just as well for just your own use.

I'm guessing the OP is working on a smaller and/or less public project and would be better off doing things a simpler way. If that is incorrect, please ignore this post.

1 members found this post helpful.

That explains a lot. Ive tried those before, but maybe by-passed through it. I was thinking for some reason, .so files require object files with them. Like a debug version. When I explore the contents, they tend ro leave specific details in them (such as my systems library path). Theres not a lot of explanations on these areas in the docs.

im gonna experiment with this again, and look for some comparison data.

debug data (example symbol names) get put directly in the ELF file (DWARF format usually)

the only full path in a ELF shared object is the loader path (ld-linux-whatever)
the loader then finds the required library
http://tldp.org/HOWTO/Program-Librar...libraries.html

it is cleaner, compared to windows

So I wouldnt have to install my own libraries in /usr/lib?

if you use LD_LIBRARY_PATH or LD_PRELOAD you can use any library from anywhere

an example of a program using those is steam
it does it so it can ship a set of common libraries for games to use, without being distro dependent
(some say having many distros is a "big problem", when it's really not and never was)

Instead of /usr/lib, I would suggest /usr/local/lib or $HOME/lib to install shared objects.

1 members found this post helpful.

The shared libraries do store a path. If you specify a folder name with the so build, it is stored in the so library. This causes a problem in ldconfig. It will take the library folder in addition to the path in the so to itself. Picture attached...

I honestly misunderstood so. This stands for shared object, so I understood this to mean debugged.

I also overlooked ldconfig. Even after a successful build, programs ran did not locate the so. Any new libraries without ldconfig ran will be missed.

I didnt intend this as a world library, just personal things of sorts.

To remedy:

1. Run gcc -fpic on my object, then a gcc -Wl,-soname,... on the object. The so is built in the same directory (leaving clutter)
2. Install library in /usr/local/lib or edit /etc/ld.so.conf with install directory.
3. Build binary with full path or -l<name>

notes: make sure prefix is lib and suffix is .so as required.

Attached Thumbnails

 

SHARED LIBRARIES DO NOT STORE A PATH !!!!

argh
use strings if you don't believe me (or readelf or ldd)

it is ld, the loader, that looks in a few directories for the requested library
try running this:
ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012

1 members found this post helpful.

stored libs and executables might store directories, where the dynamic loader will search for dependent shared libraries
See gcc option -Wl,-rpath,<path>

just a personal opinion - life is so much easier with fpc/lazarus

I build both dll and .so files with it and I found even the first one I did quite simple
(although I was familiar with lazarus itself beforehand so that may have helped)

If you're wondering I'm not especially advocating lazarus over C - I also do embedded work
in C - I just find the above to be much simpler for other work.

The only issues I've found with the various nix implementations is that there seem
to be multiple ways of handling special characters on the command line in some of
the older versions. This had me tearing my hair out to get all of them compatible
but I dont think thats an issue with recent releases.