Hello, guys! This is another newbie question from a guy trying to understand the Linux internals. This may have a lot to do with assembly programming, or not at all, but since I don't know....

The thing is I already know there are static libraries in Linux (that are embedded in the executable file when it is linked) and shared object files, that is, dynamic libraries (which are not). But there's something I don't understand very well. Some libraries have a regular version and a development version. The regular may be provided with the system, while the development one, you have to download it to compile a program with it. No idea how this would be done in assembly. I'd like to know.

Now what gets me most confused is that these development libraries usually are only necessary when you compile, but if the program is built, they could well be absent. This makes me think that these dev libraries are static, but if so, why do I need the regular version of the libraries at all? And if they were dynamic, why do I not need them once the program's been compiled?

I think I need to understand this so I can do in Flat Assembler some thing I've been doing in FreeBasic (which uses dev libraries to compile programs). In particular, access to X graphics. Am I right?

Thanks for any hint you can give me!

The development versions of the software (not only the libraries) is such version that is in process of development and this way is not recommended for everyday use, because is not as stable as the developers want it to be.

It can contains bugs, experimental features that might be later removed, and so on.

That's Linux. Different cults come up with different names for the same thing. LOL. I think Linux cults should meet up some day and start standardizing names and naming conventions before a new cult emerge and introduce other names like work-in-progress (WIP) release, KIV version, compile-this-yourself-and-see-how-it-goes release etc etc. hehe.

He, he... yeah, that wasn't what I meant. I'll give a real life example.
I use FreeBasic for my non-assembly projects. Besides, in Linux, I'm an assembly newbie. So some time ago, I wanted to make a program that used ALSA to produce sound. I assumed that, since I had installed other programs in my system and they were already producing sound and even specifically indicated they were using ALSA for their sound system, then I needed nothing else in order to compile a program that could do the same. Wrong. Reading the sample programs, I found I had to dynamically link to a library called libasound. When I tried to do this, it turned out the library was not found. I had to download it and then everything worked, but without the library, other programs would still produce sound. When I asked the FreeBasic people, they explained that, why the libasound was necessary to compile the program, my program would run without it. But this libasound.so is a shared object, therefore, dynamic. So this is confusing.

Same thing happens when I compile programs that use X11 to produce graphics. To be able to compile them, I need to download and install the libX11-dev package. But when I run my already compiled programs in an environment where this package has not been installed, they run just fine.

I'm pretty certain this same thing will happen if I want to do it in Flat Assembler, but since I'll be working low-level, I would like to understand what's special about these "dev" libraries.

Presumably some code from the dev library is being statically linked into your executable. So all you need to do is find what is being linked and duplicate that in your assembly code. And I imagine that extra code is loading/linking the .so object at startup and maybe also providing translation of calls from your code and passing them on to the .so code.

Yep... that sounds like what could be the thing.
I've just read that libX11-dev is a package that contains headers. I didn't know that headers alone (function prototypes?) could be compiled into an object file and linked to a program so that it can access functions in yet another library. Doesn't make much sense to me. But with ALSA, I really don't know. It's a shared object.

Header files are just another file as far as the C compiler is concerned. It is only by convention that people usually restrict themselves to just putting prototypes and definitions. There is no rule stopping anyone from putting an entire program in there.

axlucas..

I am trying to understand your point here... I may be wrong.

IMO, you are confusing development vs deployment. Your confusion is like asking what is JRE and what is JDK. Why sounds work when deployed (i,e in JRE) but not when you are trying to develop it yourself (ie, in JDK).

Development package is more like the SDK or development kit in Windows world. There are set of tools to develop and test your code in a confined and limited environment, so naturally static library will be more suitable in that case. Deployment environment is a different story. It has system-wide effect and they work in runtime environment, of which dynamic library is more suitable.

To make it more clear, try imagine yourself developing android apps for smartphones on normal x86 PC by using Android toolkit or development SDK. You'll understand what I meant by development vs deployment environment.

Thanks, mate. Well, I do see the difference between these two things. My real doubt is about how they work... that is, the connection between the two. In my opinion, if a kit is only for development, then it must be static. Otherwise, the program would still need it at run time. If something is dynamic, then that something should be used by the compiler and not by the program itself, but that doesn't make much sense. Now if it is static, then why use two parts: a static (dev) and a dynamic (runtime) libraries? Why not just have everything in static form or everything dynamic and not include a dev kit at all?
Makes me wonder if I can anyhow avoid using the development library entirely, even at compile time, given that it won't really be necessary later.

I have never programmed for Windows or for Android, so I'm not familiar with how that works. Only Linux and DOS, but in DOS, I understand the internals. In Linux, I don't... yet.

Hi axlucas,

Confusion seems to reign on this thread. It sounds like you're using Ubuntu or similar. Most libraries have a binary version, with a package name in the repository like (for example) libsdl2-2.0-0 (which is a game programming library). Installing this will install a .so file which is linked at run time. Most also have accompanying C header files, which you can #include in your C or C++ programs so that they "know" all the function names the library provides. These headers are provided in the packages (.debs) with the -dev suffix in the name, such as libsdl2-dev. They don't generally contain executable code, just the prototypes of the library's functions. So, you don't generally need the -dev suffixed packages for assembly language development (though they might be useful as a more human-readable reference). To use a function from a binary .so which is already on your system, you would declare it in your (ELF/ELF64) assembly source with something like "extrn SDL_Init". Then you would link the program against the .so using GCC like this:

gcc my_prog.o -lSDL2

(This assumes that you built the program with "fasm my_prog.asm" and the library is called "libSDL2.so", which may be incorrect - I'm afraid I don't have a Linux PC handy)

Hope I cleared up the confusion. Basically, you only need the -dev packages if you're using C or C++. In assembly, you just have to be aware of each function's prototype and the platform ABI so you call the functions correctly.

That was exactly what I wanted to know. Thank you so very much!!
And yeah, the problem when there's a doubt is not much that the helpers may give wrong answers, but that the askers may ask wrong questions, ha, ha. Yes. I'm using Xubuntu right now. I would like to eventually move away from *ubuntu's and move to something I have more control on, but I don't feel like I'm enough of an expert yet.

Really happy I helped! I have flirted with the Fedora family of OSs but I always find myself returning to the *buntus. They just seem to break less often.