[C++] Is there a way to convert libraries into just source code?

[Red Squirrel]

I've been wanting to get into bigger C++ projects, even toying with the idea of making a basic sandbox game. I'm not really good at graphics so not sure how far I'll even get, but just something I want to try for fun.

The biggest challenge with C++ especially in Linux is whenever you get into more complex stuff you need to use 3rd party libraries, which means dependencies are involved. It's always a gamble if it will work on one system from the other because of how terrible the library management is in Linux and how distros can be inconsistent such as where libraries are put or what the file is even called. Then you have to deal with libraries being a different version and some libraries not liking other versions etc... aka dependency hell. I want to avoid this.

When I need to use some kind of 3rd party library, is there a way to simply convert it all to regular source code, so that it can just be a regular include file and not have to depend on anything else on run time? Basically instead of having to install the library into the system, I simply make it part of my code and make it independent of the system. Is this possible? I'm going to guess it's not otherwise everyone would be doing it, and dependency hell would not even exist. But thought I'd ask.

What about static compiling, how does that work and how is it done? Would that do what I want? Essentially if I make any kind of program that I want to release to the public, I want it to quick and easy to deploy with no dependency hell involved. Just a script that runs g++ and done. No fighting with anything.

 

[Markbnj]

Not really, no, but I assume you could ship all the dependencies with the game couldn't you? Of course, even if you solve that problem you still have to deal with OpenGL and all of its inconsistencies. Personally I would look at frameworks like Unity and whatever Steam calls theirs. Let them worry about portability and platform variations.

 

[Red Squirrel]

I always include all libraries with the app even for my own stuff but the way they install may be different from distro to distro so it still screws things up. The distro itself may also not be compatible with them or vise versa.

I've downloaded programs before where you don't even need to compile it, you just run it. How do those work? Though I guess they still would have the dependency issue if they have any. Normally you can't run a binary from one system on the other though so still kind of curious how they do that.

 

[KillerBee]

sounds like a good case to use Docker

 

[postmortemIA]

Looks like you're looking for statically linked libraries. There all libraries will be linked together into executable during linking process, so resulting binary will not have (m)any external dependencies. Otherwise, libraries can be dynamically linked (which is the problem you are expressing), where you don't have to distribute the libraries (DLLs in Windows), as long as target system has compatible version of library.

First method produces larger executable, and should also have larger memory footprint. Second method lets application load libraries as needed.
The second disadvantage for statically linked stuff is that often you need to recompile them from the source code as they may not be distributed like DLL release is.

 

[Red Squirrel]

Hmm that would be nice. It would make deployment much easier. I could still release the source and it would be optional if the user wants to screw around with trying to get the libraries to link properly. How would I go about statically linking?

Actually another thing, if I go with the regular way, how do I go about making it so the libraries can just be in the same folder as the program? That alone could maybe solve the issue as the majority of the time dependency hell issues are because the library on the system is either in the wrong location, not named the same, or is the wrong verison. If I could ship with all libraries and have the program compile with them instead of the system ones that could maybe work too.

 

[Red Squirrel]

Been trying to google how I go about staticly linking an app but the only thing I'm finding is that it's something that was phased out. Pretty retarded thing, it only makes making portable apps that much harder. The whole shared library thing is just a huge disaster.

Do I have any other options? Is there a way I can just include the libs with my app instead of having to install them? I just want to be able to run a single script that makes my app compile and work on any system without needing to rely on anything external. Why do they make this so hard?

This is probably the biggest reason Windows is king. Writing portable software for it is much easier. Heck, you can just make an exe and it will run on any system. I understand Linux wants to discourage that because they want the source to be with it, but geeze at least make it easier to compile on any system.

 

[Merad]

Been trying to google how I go about staticly linking an app but the only thing I'm finding is that it's something that was phased out. Pretty retarded thing, it only makes making portable apps that much harder. The whole shared library thing is just a huge disaster.

Do I have any other options? Is there a way I can just include the libs with my app instead of having to install them? I just want to be able to run a single script that makes my app compile and work on any system without needing to rely on anything external. Why do they make this so hard?

No. There are only 3 options: dynamic linking, static linking, and compiling the library as part of your project (which is really just a slight variation on static linking).

Static linking is usually frowned upon for a couple of reasons:
1. Wasted memory and HDD space. If multiple applications use the same library, each one loads its own copy of the library's code into memory. A shared library will be loaded once by the OS.
2. Impossible to update. If [insert library name here] is found to have a major bug or security hole and you've static linked it, then you (or the user) has to recompile the library AND recompile your application. If the library is dynamically linked then a single compile and update deploys the fix for all programs.

The biggest problem you're likely to run into with static linking is that many libraries to include build configurations for a static library target, and some of those that do have different (more strict) licensing terms on static linking.

This is probably the biggest reason Windows is king. Writing portable software for it is much easier. Heck, you can just make an exe and it will run on any system. I understand Linux wants to discourage that because they want the source to be with it, but geeze at least make it easier to compile on any system.

Believe me it's just as much of a pain in the ass on Windows. Remember, windows is responsible for creating the term "DLL hell" back in the Win95 days. The real difference is that on Windows compiling from source and installing by hand is extraordinarily rare. Most of the derpiness is hidden behind installers, so it appears to just work. Linux is actually much better at library management if you're using an application and/or library that's kept up to date in a package manager.

It sounds like you need to look at autotools. I've never really had a need for it but AFAIK it's supposed to handle this kind of system specific configuration.

 

[Red Squirrel]

Hmmm I think compiling the library as part of the project is what I want. Maybe I just was not explaining well enough. Basically instead of having to install the library on the system and praying that my program and/or the compiler finds it, I just want the library to be part of my code. I'm speaking strictly about open source libraries where I need to install the library from source anyway so as far as I can understand all the code required to make the lib file would be available in the install package. I just want to make that code part of my program instead of my program having to link against the library.