Is there a way to convert Linux C++ lib files to code?

[Red Squirrel]

I hate dealing with dependencies and lib files and all that crap in Linux as it's always a different fight from one system to the other as there's no consistency where stuff goes so stuff like lib paths, versions, etc are different and break.

I'm currently dealing with having to rewrite an application because of this as it wont compile on a new server due to that OS's libs being different or what not.

When using something like say libpng or mysql++ is there a way to simply convert those libs as pure include files so that when I compile my app all that stuff is simply included and it does not depend on anything else?

Failing that is there a way I can simply include the lib files with my program and have it link with those and not have to check the system if they're "installed"? Essentially I want my app to compile and run on ANY system without having to go through dependency hell. half the battle of dependency hell is making sure they're installed, the other half is making sure the program knows where to look because each system installs them in a different spot. I want to do way with having to install libs and I just want them included with my app. Is this something possible to do?

 

[exelias0]

It sounds like what you want is static linking instead of dynamic linking. This bundles all of the libraries and application code into one big executable file. I believe the convention in Linux is a .a extension for static libraries and .so for dynamic, so if you're using prebuilt libraries look for the .a files and set up your linker to use them instead.

 

[jimmyb]

You can use a linker to combine object files into a single executable.

My advice is to figure out the dependency issues. Search paths for dynamic linking are both standardized and documented.

 

[devman]

I hate dealing with dependencies and lib files and all that crap in Linux as it's always a different fight from one system to the other as there's no consistency where stuff goes so stuff like lib paths, versions, etc are different and break.

I'm currently dealing with having to rewrite an application because of this as it wont compile on a new server due to that OS's libs being different or what not.

When using something like say libpng or mysql++ is there a way to simply convert those libs as pure include files so that when I compile my app all that stuff is simply included and it does not depend on anything else?

Failing that is there a way I can simply include the lib files with my program and have it link with those and not have to check the system if they're "installed"? Essentially I want my app to compile and run on ANY system without having to go through dependency hell. half the battle of dependency hell is making sure they're installed, the other half is making sure the program knows where to look because each system installs them in a different spot. I want to do way with having to install libs and I just want them included with my app. Is this something possible to do?

First, Linux isn't an OS. RHEL, Arch, Debian, Slackware, are OSes, and they are different OSes with different packaging requirements, library stability, etc, etc. They just happen to be more related to each other than they are to Windows.

You'll want to look at the how each OS packages software, the guidelines are usually well documented (there are lots of individual package maintainers that all have to do the same thing for lots of packages). You may need to loosen your dependency requirements if you want your package to build in very different OSes like Debian (conservative) and Arch (cutting-edge). Often times projects cope with this by offering build options that allow tailoring the build to presence or absence of different libraries (perhaps even at different versions).

 

[cyclone3d]

You will want to static link your code and use the source from the libraries instead of trying to deal with different versions of the libs.

Some of those libraries can be a pain to get to compile, but maybe that is just because I am using them on Windows and they are generally tailored to be used in a Linux based OS.

Most of the libs come in pre-compiled versions for Linux but not for Windows.

 

[Red Squirrel]

What's the best way to static link? Typically the instructions that come with the libs don't say anything. They just say to do ./configure make make install and add a certain flag(s) to g++ command. From that point on you pray that it actually compiles, and runs. Was googling this and I read that they removed the ability to static link, is that really true?

But yeah I'm thinking static link may be the answer, that or if there is a way to simply make my program look for the libs in it's own folder instead of looking for them on the system. Not sure if that's possible though. Basically instead of having to install the libs it would be nice to just use the source as part of my program. No special G++ flags, just regular code being compiled. A lot of those flags require stuff to be at specific places and be a specific version and that can change from system to system, which is where stuff breaks.

 

[jimmyb]

gcc/g++ does linking by default

So:

gcc -o <output file> <object file 1> <object file 2>...

 

[Red Squirrel]

Object file would be the lib file right and I can give it a relative path? So this will make it use the lib file that I include and not search the system for one that is installed? That may be the solution right there. I'll have to play around with that.

 

[jimmyb]

"lib" file is somewhat ambiguous, but if it's a .o or .a then it is a library meant for static linking.

Some more information:

What's the best way to static link?

Ultimately a linker is going to get run. If you're using the gnu toolchain this is probably gcc/g++, etc.

If you're asking what the "best way" is at some other level of abstraction, then that depends on the build procedure and tools you're using.

Typically the instructions that come with the libs don't say anything. They just say to do ./configure make make install and add a certain flag(s) to g++ command.

The installation instructions for a library generally aren't going to give explicit instructions on how to link their libraries into other applications because it's a standard procedure (see my previous post). They may tell you where the libraries get installed on your system, but what you do with them is up to you. It is assumed that you know how to statically or dynamically link, or that the build procedure for your application will handle this for you.

or if there is a way to simply make my program look for the libs in it's own folder instead of looking for them on the system.

There is a way. The LD_LIBRARY_PATH environment variable defines these paths - see also ldconfig.

it would be nice to just use the source as part of my program.

Do you have the source code for the libraries? If yes, then you can just use it. It might be a monumental amount of effort getting it to compile though.


I'll reiterate that it is probably better to figure out your dependency problems.

 

[jimmyb]

Some of our EDA vendors supply monolithic statically linked binaries, so I guess it's not totally unheard of in (some) industry. I don't think it's usually considered a best practise, but I'm not a software engineer so idk.

 

[jimmyb]

My recollection is you can also statically link against libraries in the search path with gcc using:

gcc -o <output file> -l<libraryname>

I think this may be preferred for a lot of scenarios, but ultimately it's doing the same thing.


Edit:

I noticed this comment:

So this will make it use the lib file that I include

You don't include "lib" files; you include source code and/or headers. #include does not tell the linker how to behave; it's a just preprocessor directive.

Also note that if you're switching to static linking, you probably need to update your code so that it doesn't try to dynamically link the library at runtime.

 

[Red Squirrel]

Yeah but I'm hoping I CAN include the libs (include as in, having them along with the rest of my code) so that they don't have to be installed. Basically I want to be able to grab my entire project folder, drop it on any system, and have it compile/run.

Though, if I have the libs installed on my dev machine and statically link, will the binary then work on any system? That might be my best bet.

 

[Red Squirrel]

Yikes can't even compile mysql++, I end up in a dependency loop where I need to install mysql-devel, but mysql-devel requires mysql-devel. What a mess. Think I'll just rewrite my program so I don't need mysql++ that will fix a lot of my issues. Probably easier to just get around even needing the dependencies in first place instead of trying to get them to work. Though some may be harder than others like png, but I think if I use libpng directly that one is common enough that it should already be on most systems anyway. The system dependencies are not too bad, it's the oddball ones that are.

Though if I do get this to work, all I need to do is statically link then the binary should work on mostly any other system right?

 

[devman]

Can you specify what environment your compiling in. A demonstration of the problem would be even better.

 

[jimmyb]

Probably easier to just get around even needing the dependencies in first place instead of trying to get them to work.

I would spend some time learning about the fundamentals of compiling and linking. It's such a basic thing that anyone working with compiled languages should know.

Designing out features because you can't figure out how to link a library is a bit of a monocle popper.

 

[Red Squirrel]

Can you specify what environment your compiling in. A demonstration of the problem would be even better.

CentOS 6.5, though I want it to work in anything. Right now I'm not even at the compile stage as I just want to figure out a way to make it more portable. Before I migrated to a new server this was the compile string that worked:

g++ -o uogpoller uogpoller.cpp -g -w -lpthread -lmysqlpp -L/usr/lib64/mysql -lmysqlclient -I/usr/local/include/mysql++/ -I/usr/include/mysql

Though that is missing some stuff like the png stuff which I took out while troubleshooting something else. For now I just want to get mysql++ to work, or code a work around, then I'll worry about the rest. The png library I was using had a memory leak so chances are I will skip it and use libpng directly. I think that one should be easy enough as it's a fairly standard one. Should have done that from the get go.

Is there a tutorial somewhere that explains in general how all this shared library stuff works and ways to make apps more portable? It could definitely help to try troubleshooting these issues even with other programs that I'm trying to install. One of the biggest Linux issues is dependency hell but knowing more how it works at the low level could maybe help troubleshoot stuff.

I managed to fix a dependency issue that was stopping me from installing mysql++ on the new server so chances are I'll get it working, but the issue still remains that I need to fight with this stuff for every box I want to install this one, and I want to break away from having to deal with that.

 

[jimmyb]

g++ -o uogpoller uogpoller.cpp -g -w -lpthread -lmysqlpp -L/usr/lib64/mysql -lmysqlclient -I/usr/local/include/mysql++/ -I/usr/include/mysql

Highlighted in red are all arguments that tell g++ to statically link those libraries. Note that this includes mysqlpp and mysqlclient

What error do you get when you try to run the binary on a different machine?

 

[Red Squirrel]

I managed to get it to a point where I can compile it now. But when I try to run it I get this:

./uogpoller: error while loading shared libraries: libmysqlpp.so.3: cannot open shared object file: No such file or directory

That's without any of the png stuff though, I took all that out just so I can troubleshoot one thing at a time.

I found something on google that if I want to compile statically I just put -static as a compile argument, not sure if this is right but I tried it, but when I do it wont compile at all:

/usr/bin/ld: cannot find -lpthread
collect2: ld returned 1 exit status

Issue is even once I do get this to work, it will be back to ground 0 next time I want it to work on another machine. There has to be a better way where I can include all the code required for the program to work, within the program/source instead of having it depend on the system having it already.

 

[Red Squirrel]

Another downside of libraries.... they must have made some changes of sorts, now code that used to work no longer works. I actually managed to get it to compile on the production server by commenting out all the code that handles pngs (a small part of the app which I can go without for now) but now it's complaining at code that used to be legal but now I guess is not:

In file included from sources.h:1,
                 from uogpoller.cpp:35:
includes/ShardListEntry.cpp: In member function ‘void ShardListEntry::Poll()’:
includes/ShardListEntry.cpp:59: error: size of array ‘m_row’ has non-integral type ‘const char [13]’

Line 59:

 SocketClient client(string(m_row["slogonserver"]),(int)(m_row["slogonport"]));

SocketClient is a custom wrapper around the tcp/ip code the first argument is string and second is int. m_row is a Row object from mysql++. Really not sure what it's complaining about.

But at least I got the hard part figured out, it gets to the point where I get regular code errors now. If I add dummy data there it actually compiles AND runs so I guess that's a start.

Can't say the same for dev/test environment though, it's still a disaster there.

 

[jimmyb]

I found something on google that if I want to compile statically I just put -static as a compile argument, not sure if this is right but I tried it, but when I do it won't compile at all:

/usr/bin/ld: cannot find -lpthread
collect2: ld returned 1 exit status

You *could* try dynamically linking pthreads and everything else static with something like:

g++ ... -Bdynamic -lpthreads -Bstatic <everything else> ...

 

[jimmyb]

Another downside of libraries....

Literally the entire software industry uses libraries extensively and have figured out effective ways to manage them - you should interpret these serious difficulties as indications that you haven't learnt how to use them properly and motivate yourself to do that, no disrespect.

If you're planning on working with software as career, these are things you need to figure out how to use properly.

 

[Red Squirrel]

This is just a hobby project. I just need this to be portable so I can stop having to screw around with the library crap and actually get to coding. With all the aggravation this has caused me over the years I would have been better off writing my own connector that does not use dependencies and just talks directly via tcp/ip. Something I still want to look into but I'm hoping to at least get it partially working for now till I can get around to that. The shard library model has always been problematic as a user or a programmer. I don't know how many times I've had to fight in Linux because something does not want to install due to dependency hell. The worse is version based dependencies, where the dependency it wants is actually there but is the wrong version. With packet managers you don't really have much control over what version it installs, it just puts whatever is in the repo, and even if you did have control then it will just break something else.

Windows has it right. Make a exe, execute the exe, the exe works. Mind you there is dll hell in windows too.. guess you can't win.

 

[jimmyb]

just talks directly via tcp/ip

If you're using tcp/ip, then you're almost certainly using a library; otherwise I guess you're implementing the network stack by yourself.

The shard library model has always been problematic as a user or a programmer.

The shared library model is a basic component in driving the rapid pace of software development over the last several decades. It has its learning curve and drawbacks, as you've noticed.

Windows has it right. Make a exe, execute the exe, the exe works.

The exe only works if it can dynamically load the libraries it requires. It suffers the same fundamental problem as you trying to run binaries on different machines.

The difference as far as I can tell, is that when you download an exe it has *already* been statically linked and prepared for dynamic linking by professional software engineers, which is what you're struggling to do in the first place.

Mind you there is dll hell in windows too.. guess you can't win.

"dll hell" *is* dependency hell. DLL = dynamic linked library. The difference is the file extension.

 

[Red Squirrel]

The berkely "library" is built into the system, that's different. I'm talking about external non standard ones. Those are the ones that are problematic, because they're all implemented differently and inconsistently from system to system. Every system it's a new fight to get it working. Some libraries are worse than others. Mysql++ seems to be very notorious.

For example on my production system I finally got it working after lot of fighting but now it does not like my older code. So I'm half way through that battle.

On my dev box, the program compiles but wont even run because it can't find the library even though it's installed. Both systems have it installed yet they all act differently with different problems.

It's annoying have to spend more time fighting with this dependency hell stuff than actually coding. Trying this but still not working:

g++ -o uogpoller uogpoller.cpp -g -w -Bdynamic -lpthread -Bstatic -lmysqlpp -L/usr/lib64/mysql -lmysqlclient -I/usr/local/include/mysql++/ -I/usr/include/mysql

I still get this error when I try to run it:

./uogpoller: error while loading shared libraries: libmysqlpp.so.3: cannot open shared object file: No such file or directory

I actually found the file it wants but even if I put it in the same folder as my app it wont look at it. I'm guessing apps are hard coded to look in a very specific location on the system.

 

[jimmyb]

Those are the ones that are problematic, because they're all implemented differently and inconsistently from system to system.

If you don't have control of what libraries get installed on the target systems, then as has been discussed, you'll want to statically link those particular libraries and distribute the binary.

I don't really want to be any more contrary, but if there's significantly API-incompatible libraries installed across systems that should be running the same tools, then there is a sysadmin problem going on.

 

[Red Squirrel]

Yeah trying to statically link but still getting issues.

I think I might be getting somewhere though, at least on the dev box. I opened up the actual binary to see if I can find some hints as to where it's looking for the libraries because it keeps saying they can't be found. I found /lib64 in there, it was referring to something else, but for shits and giggles I copied the libmysqlpp.so.3 file after doing a system wide search for it, to that location, and the app runs now.

Hopefully now that I got this to work in dev I can just get the static linking to work so that my app will run on any system. So I just want to be clear, in this string:

g++ -o uogpoller uogpoller.cpp -g -w -Bdynamic -lpthread -Bstatic -lmysqlpp -L/usr/lib64/mysql -lmysqlclient -I/usr/local/include/mysql++/ -I/usr/include/mysql

-Bdynamic makes everything after that link dynamicly
and
-Bstatic makes everything after that link statically?

And linking statically means it embeds the library right into the binary and it will call that library instead of looking for it on the system right? So as long as the binary is run on the same architecture (ex: Intel ) then it will work?

 

[jimmyb]

I opened up the actual binary to see if I can find some hints as to where it's looking for the libraries because it keeps saying they can't be found. I found /lib64 in there, it was referring to something else, but for shits and giggles I copied the libmysqlpp.so.3 file after doing a system wide search for it, to that location, and the app runs now.

You need to make sure that libraries are installed to a location that the linker is going to look for them. This is means either choosing your installation directories appropriately, or configuring your linker to look where required.

-Bdynamic makes everything after that link dynamicly
and
-Bstatic makes everything after that link statically?

That is my understanding - I've always just let the linker make its own decision.

And linking statically means it embeds the library right into the binary and it will call that library instead of looking for it on the system right?

Yes.

So as long as the binary is run on the same architecture (ex: Intel ) then it will work?

The dynamic linker won't fail on those libraries, because it won't be trying to link them. However, there are other reasons the binary might not be portable (such as ISA, as you mentioned).

 

[Red Squirrel]

How do I make sure the libraries are in the right location? It seems every distro shoves them wherever it wants. The only way I've ever been able to find them is using find / | grep -i [filename] which takes a long time since it checks all network drives too. Most of the time they're in /usr somewhere but sometimes there's some other random folders in / where they may be like /lib or /lib64 and probably others that I have not run into yet.

I've gotten really close to being able to compile statically but it's still complaining about libmysqlclient.so.18 when I try to run it on the other server. From what I read I need to find a .a file on the dev server and make it use that, and so far no luck, and even if I do find it, no idea how I tell it to use that instead of the .so.

 

[jimmyb]

How do I make sure the libraries are in the right location?

Most installation procedures (ex: apt-get, make install, etc.) will put the libraries in a correct location. If this is not happening it is potentially a bug.

ldconfig -p will tell you what's visible to the runtime linker.

It seems every distro shoves them wherever it wants.

It's actually reasonably standardized

Generally you're going to find libraries installed in:

• /lib
• /usr/lib

and their 64b counterparts. They'll be put in each according to the rules described in the link above.

This goes without saying, but when you're doing software development and deployment you should be familiar with how your operating systems work.

using find / | grep -i [filename] which takes a long time

Yes that would take a long time - it's a perversion of the find command. You are literally printing out every file and directory to standard out and piping that to a grep. ie. you are not using find to do the actual finding, you are using grep.

find /search/path -name <pattern>

There are other arguments such as -mount to prevent find from traversing into other filesystems such as network drives.

I've gotten really close to being able to compile statically but it's still complaining about libmysqlclient.so.18

My interpretation of this is that you did not actually statically link mysqlclient. .so == shared object.

 

[Red Squirrel]

Seem to not be able to find libmysqlclient.a anywhere which is probably part of the issue. When I tell it to statically link if the file is in the same folder as the .so does it automaticly use it?

From what I googled I need to install mysql-devel but that is installed already on both systems.

 

[jimmyb]

Seem to not be able to find libmysqlclient.a anywhere which is probably part of the issue.
.

You may not have a static mysqlclient library installed.

The .so cannot be used for static linking.

 

[Red Squirrel]

Hmm guess static linking is not really the answer either then, as it requires specific libs to have specific files which wont always be the case.

Come to think of it, is there a way to get a list of all the libs and paths that a binary searches for? And is there a way to change those paths at compile time? What I could do is once I do get it working on one system, I could then run whatever command it would take to get those paths/libs, copy the libs over to a folder, then recompile the app to use the ones from that folder. Idealy I'd want to automate this as theres probably 100's of files. Is there a way to do that? Or are lib files designed specifically for one system only? The idea is I only want to have to fight dependency hell once, after that I want to be able to package everything up and have my app work on any system. I'll still static link what can be statically linked but still have to deal with some shared libs no matter what.

I did manage to find that libmysqlclient.so.18 file on my dev system and copied it on the prod system in all the lib paths and it seems my app works now, well to the extent that I expect it to, I was still in middle of a rewrite before my server migration so I still have to fix that. The actual coding is the easy part though.

I still need to get libpng to work but think I'll worry about that battle another day... I may also just make the web front end generate the graphs using html5 canvas.

 

[devman]

Hmm guess static linking is not really the answer either then, as it requires specific libs to have specific files which wont always be the case.

Come to think of it, is there a way to get a list of all the libs and paths that a binary searches for? And is there a way to change those paths at compile time? What I could do is once I do get it working on one system, I could then run whatever command it would take to get those paths/libs, copy the libs over to a folder, then recompile the app to use the ones from that folder. Idealy I'd want to automate this as theres probably 100's of files. Is there a way to do that? Or are lib files designed specifically for one system only? The idea is I only want to have to fight dependency hell once, after that I want to be able to package everything up and have my app work on any system. I'll still static link what can be statically linked but still have to deal with some shared libs no matter what.

I did manage to find that libmysqlclient.so.18 file on my dev system and copied it on the prod system in all the lib paths and it seems my app works now, well to the extent that I expect it to, I was still in middle of a rewrite before my server migration so I still have to fix that. The actual coding is the easy part though.

I still need to get libpng to work but think I'll worry about that battle another day... I may also just make the web front end generate the graphs using html5 canvas.

Squirrel, your basically asking for the the GNU Build System (autoconf, automake and libtool)

If you want to create libraries suitable for static linking your likely going to have to compile your dependencies from source, as anything they depend on will have to be statically compiled in to them as well.

 

[Red Squirrel]

I did compile mysql++ from source as far as I'm aware. tar.gz files where you do ./configure, make, make install is source right?

Do you have more info on the GNU build system, I imagine it may be worth looking into. I just want to be able to package my apps in a way that it has everything needed for it to compile and run so that I can drop it anywhere and it will work.

 

[devman]

I did compile mysql++ from source as far as I'm aware. tar.gz files where you do ./configure, make, make install is source right?

Do you have more info on the GNU build system, I imagine it may be worth looking into. I just want to be able to package my apps in a way that it has everything needed for it to compile and run so that I can drop it anywhere and it will work.

./configure --enable-static

although it says that building static libraries is default. Did you check the output targets thoroughly?

http://dev.mysql.com/doc/refman/5.0/en/source-configuration-options.html

 

[jimmyb]

I did manage to find that libmysqlclient.so.18 file on my dev system and copied it on the prod system in all the lib paths and it seems my app works now

I'm glad you got it working. Be warned that copying over files piecemeal like this is setting yourself up for lots more headaches in the future.

 

[Red Squirrel]

Yeah I'm afraid it may be an issue. Could not really see any other way of doing it though as despite all the proper stuff being installed it still complained about that file.

The whole static linking thing does not seem to work very well either because of the fact that it requires specific files that may not ship with each library, as I've just seen here. Not all the proper .a files were included with mysql++ (Even after compiling it) so that I still ran into that issue with that libmysqlclient.so.18 having to be dynamically linked anyway. While I did manage to get it working on prod I ended up having to recompile the program anyway. So on another system it may not compile because of that file not being there again. I can possibly include that file with the program with a bash script that puts it in the right location, but then that may potentially be an issue as well and it's still not guarantee it will work.

What exactly is a library file anyway, like, what does it do differently that a header can't do? For something like a mysql connector, why can't they just make a header that has classes and functions and code that is an implementation of the mysql protocol and connects that way? What does making it a library do that can't be implemented in pure code? Just trying to understand the reasoning as to why libraries are used instead of plain code, if there's any and what makes it so they can't be converted to regular code?

 

[Tawnos]

What exactly is a library file anyway, like, what does it do differently that a header can't do? For something like a mysql connector, why can't they just make a header that has classes and functions and code that is an implementation of the mysql protocol and connects that way? What does making it a library do that can't be implemented in pure code? Just trying to understand the reasoning as to why libraries are used instead of plain code, if there's any and what makes it so they can't be converted to regular code?

Oh geez, I think you need to go read some of the basics of compiling and linking. A header merely provides signatures of what the library contains (not 100% true, but true enough here). To steal from this stackoverflow answer, "The header is a phone number you can call, while the library is the actual person you can reach there!"

Extending that a bit to give you a super short crash course in what happens when you "build", there are two main phases to a build, compiling and linking. I'll skip preprocessing, how template metaprogramming is compiled, etc. The short version of compiling: taking various bits of source code, e.g. C/C++, and transforming them into some output format, e.g. binary machine code. The short version of linking, biased towards statically linking: taking the various output format pieces and smashing them together in such a way that references between the various pieces may be resolved within the self-contained binary file.

Extending the phone number/person you call analogy, at the end of compiling you have binary code that says "when I want to use so and so function I call this phone number with this extension to reach them". Linking is like moving all of you into the same building, then replacing that phone number with their extension alone so you can call them within your building. Since the header just lets you know that there's a phone number to reach someone, it doesn't do you any good to just have that if there isn't actually someone you can reach.

This is a very abbreviated view of the process and not 100% technically correct, but hopefully it helps you start understanding why you need a library (not even sure what you mean by that - pure c/c++ code? pure machine code? pure intermediate language code?). If you mean "why can't I just copy their c/c++ source code and use it directly in my program - you can, but the point of a library is to give you a self-contained unit that has certain known points you may contact and use, hiding you from what's going on inside that unit.

I'd strongly suggest reading up about the phases of building an executable before mucking about further. It will serve to help you significantly in any future build issues you encounter.

 

[jimmyb]

The whole static linking thing does not seem to work very well either because of the fact that it requires specific files that may not ship with each library, as I've just seen here. Not all the proper .a files were included with mysql++ (Even after compiling it) so that I still ran into that issue with that libmysqlclient.so.18 having to be dynamically linked anyway.

That is either a sysadmin issue or not knowing how to use the compiler toolchain.

What exactly is a library file anyway, like, what does it do differently that a header can't do?

A compiled library is a file or collection of files containing the actual machine code that gets executed. It is the compiled source code for the library that you are using.

A header file is source code typically containing things like function and class declarations (not definitions). You need these things to be declared otherwise the compiler would have no idea how to interpret references to them in your source code. Header files are typically inserted directly into your source code by the #include preprocessor directrive.

Including header files and linking in libraries are complementary, not alternatives. When you include header files you also need to link in the object code for what is declared in the header.

why can't they just make a header that has classes and functions and code that is an implementation of the mysql protocol and connects that way?

Because that's not what header files are. Header files typically do not contain the actual implementation. The primary point of a header file is to provide declarations but not definitions.

What does making it a library do that can't be implemented in pure code?

That's called source code. You have that already.

Just trying to understand the reasoning as to why libraries are used instead of plain code,

Making it a compiled library means that every user doesn't have to struggle to compile from source every 3rd party package each time they want to use it. It also means you can update the library without having to recompile everything that uses it. It means that you don't waste disk space (and memory) having multiple copies of the library across all the programs that use it. I'm sure there are lots of other benefits.

In fact, compiling big packages from source is often a lot harder than just linking in a library. You already discovered that compiling mysql from source is not trivial - that's why they provide build scripts with the download.

Would you like to compile stdio, stdlib, pthreads, etc every time you write a program? (hint: you are linking in these libraries)

if there's any and what makes it so they can't be converted to regular code?

As I mentioned, if you want to use the source code you can try that.

If you're asking how to convert a compiled library into source code, I suppose you could run the libraries through a disassembler and inline that into your C source using asm("...") calls. That would be absolutely insane though.

 

[jimmyb]

Oh geez, I think you need to go read some of the basics of compiling and linking.

Yep. If you're working in compiled languages, this should be figured out within a couple weeks of "hello world" imo.