I have an executable file (foo.exe) with one library which has been linked statically.
I updated this library. Is there any way to update exe file with the updated library without need to recompile the executable file. I do not have access to the source code of the executable.
Executable and lib files written using Visual C++ 2010.
The executable doesn't store information about which libraries were compiled statically into it, nor has it symbol tables which are necessary for linker.
Well, theoretically, if you are not afraid of reverse engineering and patching the executable in its binary format, you can try to locate the old library code in the disassembler of the .exe and carefully change the .exe so that it executes code from the new library. But it's a very hard and fragile thing to do even if the library has only a couple of functions, and it's in fact of the same complexity as decompilation of the executable and recovering its sources.
So, while there is a theoretical possibility to replace a static lib (and, in fact, to replace anything you want), it looks a very unreasonable thing to do.
Related
So, suppose I have static library (.a file) which was compiled with debug symbols. When I debug code that uses that static library, obviously I can't step into library functions. Is there any way to provide path to library source files, so I could step into library code when debugging?
The reason I ask this question, is because when I stepped into static library function in Clion, it opened disassembly and prompted me to supply source file. After I supplied it, I could debug code in static library. I don't have Clion on my current computer, I use VScode + MSYS2 MinGW x64 toolchain and I want to know if it possible to achieve something similar.
The reason I don't use source files directly is because I'm not experienced enough to do so. The project that library comes from, is quite complicated and relies on make files (which I am not familiar with) and has a lot of dependencies.
I have a program which statically links to another library in linux using -L(mylib.a) when compiling (using eclipse cdt).
To my meager understanding, the fact that the link is static means that the library is inserted into my binary. Does this mean that if I make a change to mylib I need to recompile my binary?
I assume so, but I wanted to make sure, as it is a big overhead in time. Note that if a change was made to mylib, then eclipse recognizes that it needs to be recompiled, but it doesn't recognize that the binary itself needs to be recompiled, even though it links to the mylib.
If you did not change the interface of the library (i.e. the headers), only a re-link is enough.
Yes, You should rebuild your code with the modified library to produce the binary which links to the new and updated library.
The building of a project can be broken in to two milestone phases:
Compilation:
During this stage the compiler compiles each Translation Unit. It checks the source code for valid syntax etc and produces object files.These object files contain the assembly code output of the source code.
Linking:
During this stage the linker links together the object files and the libraries to generate an executable.
When a application or project uses a static library it includes the header file which is typically called as library interface which contains the list of api and other construct which the application uses.The application also needs to link against the library file.
Obviously, if the interfaces are intact ie the library header file included by your application is unchanged, a compilation is not required but you just need to link to the updated library.
However, I dont think there is a way to just relink updated libraries through eclipse IDE so you should rebuild your project which would essentially do the needful.
i.e:
recompile your project and relink the new library to it or
just relink the new library to your project.
This question is surely answered here somewhere, but I couldn't find it. I've been writing Java for over a decade now and my C experience was on Unix, so I'm kinda at square one here. In my Unix experience, someone else wrote the makefile and it just worked.
I have downloaded the C source code for libtar-1.2.11 from feep and ran make on it from inside of cygwin. This created a .a file and a .exe file. The EXE file appears to essentially be tar to run on Windows, but what I wanted was for the libraries to read and process the file in my own code.
If I remember correctly, those should be in the .a file (archive??) and this needs to be linked into a library that I can use from my C++ program. So I'm looking for a way to do that.
I am writing a library that will use a .tgz file and so I want to use this library. I think I'd like to turn libtar into a DLL as well as create a DLL myself for use in other languages.
So, how do I turn my .a file into something usable by other apps, and how do I access it from inside my code?
The generated libmylib.a is actually an archive of all *.o for libtar-1.2.11.
you can verify this by doing nm libmylib.a, it will print all the *.o files.
Write your code, and link:
gcc -o my_application my_application.o -lmylib
You generated this with cygwin, you can't generate a dll out of that as far as i know.
Well, a DLL is the equivalent of a shared library in Unix (a .a is a library for static linking, the Windows equivalent being a .LIB file), so you want to build a shared library.
Indeed, when you build as
make LDFLAGS=-shared
the resulting libtar/libtar.exe will actually be a misnamed DLL.
Note, however, that a cygwin-translated DLL is something different from a native Windows DLL and will always depend on Cygwin DLLs (and potentially even an installed Cygwin environment) to run, so if you plan on including it in native Windows code, this is probably not an approach you want to pursue.
May I suggest that you switch from the plenty dead (last release in 2003) libtar to libarchive, which comes with native Windows build instructions?
I am currently working in Ubuntu Linux. I am working with
a .hpp file and .cpp file. From these two I am
creating an .a file (like a dll in order to use and work with
my application on any computer that has linux installed).
I mention the fact that both .hpp and.cpp are in folder 1.
I would like to ask :
If I include in .cpp a header from a folder like:
#include "/home/tests/folder1/folder2/header.h"
will this work correctly after i create the .a using ar rcs and send my .a on another computer?
does the path to a specific header from a folder influence the .a created?
If I had to download for example gsoap in order
to accomplish my task, after I've created
the .a file that contains a lot of .xml and .cpp/.h files
from gsoap and from my .h and .cpp file do I need
to create a makefile in order to download gsoap
on the computer where I want to use my .a (or dll in windows)
application?
"Any computer that has linux installed" isn't going to work. Linux encases a wide variety of platforms and architectures, unlike Windows which generally encases only two (and the 64-bit versions are backward compatible with the 32-bit versions, so the .dlls always work).
As already mentioned elsewhere, a .a is a static library and is equivalent to a Windows .lib, not a .dll. The Linux equivalent to a Windows .dll is a .so "shared object".
No. #includes are resolved by the pre-processor in a step prior to compilation. The contents of the file are literally inserted into the copy of your source file in memory, then the whole lot is compiled. The string with the folder does not exist in your actual compiled module.That said, writing absolute paths is very bad form. It means you cannot move your development environment/directory anywhere. Use relative paths: they should be relative to your current working directory and/or to your defined include path. Read your toolchain's documentation for more information.
If you statically link gsoap, then you don't have to do anything. It's compiled into your project.If you want to dynamically link it, then your .a should not contain any .cpp files from gsoap. The target computer must have gsoap shared libraries installed, and this will be a required dependency that your installer or your user must resolve.Makefiles do not download dependencies. Package managers do.
Actually, a ".a" file is an archive file. Linux chose that format for its library files, so you can compare it to ".lib" (".so" is the rough equivalent of ".dll").
There are a number of stages of compilation: preprocessing, compiling, assembling and linking.
Preprocessing effectively answers your first question because code in the .h/.hpp file is inserted into the .cpp file, meaning that when your code is compiled, all code that is necessary to compile the .cpp file successfully is in that one file.
Compiling turns your code into assembly instructions for the specific computer that you're using. This means that if your code was built to run on a PowerPC computer (Mac), your code would use machine instructions that any PPC computer could use (meaning that Intel, AMD, SPARC, Alpha, etc. computers couldn't use your code). This answers your question about moving a ".a" file to another computer - you can use it as long as the computer's processor AND operating system is compatible (you may have a 64-bit processor, but that doesn't mean 32-bit Windows will let you use it to its full capacity).
Assembling converts the primitive text-based assembly instructions into machine instructions that the processor can understand. This creates an object file (.obj on Windows, .o on Linux). This file is what goes in the library (.lib on Windows, .a on Linux). There are other names for machine instructions such as "machine code" and "object code", and any one of them can be used to describe the same thing.
Linking is the last stage. It takes the necessary code from libraries and the various necessary object files and turns them into an actual binary (.exe file on Windows, Linux doesn't need an extension because of how it is designed). This is your application.
Because linking is the last stage, the gsoap library (for example) must be specified in addition to your library or else the linker will say it couldn't find certain "symbols". However, as with your library, the gsoap library must be on that computer to be able to use it. Installing it with the package manager is preferred when possible, but if you can't do that, you need to compile it on that computer. If you're moving from a PPC computer to an Intel/AMD computer, you would also need to re-compile your library as well as gsoap (if you couldn't install gsoap via package manager).
"does the path to a specific header from a folder influence the .a created?" - Only may be debug information. Nothing that would prevent it from working if you copy it to another place.
*.a is a static library. It is like *.lib in windows - not like *.dll
You can move any static and dynamic libraries (*.a/*.so in linux, *.lib/*.dll in windows) to any folder/computer/planet you like and use it there while dependencies are satisfied (available all the necessary dynamic and static libs, software, hardware that your library depend on). Of course running the code using your library will require the CPU architecture you've compiled for and all dynamic libs your code uses directly or indirectly.
Not directly related to the question asked: don't #include files by absolute paths. Ever. Define and use include directories. It is a matter of style and readability. Includes like "/home/user/working_dir/blabla.h" or "D:/working_dir/blabla.h" or "..\..\some\directory\blabla.h" is ugly and unmaintainable. Includes like <blabla.h> or <blabla/defs.h> is perfect for library APIs and like "blabla.h" or "subdir/blabla.h" is OK for internal headers.
I'm learning C++ and came across those *.lib files that are obviously used by the linker. I had to set some additional dependencies for OpenGL.
What exactly are library files in this context used for?
What are their contents?
How are they generated?
Is there anything else worth knowing about them?
Or are they just nothing more than relocateable object code similiar to *.obj files?
In simple terms, yes - .lib files are just a collection of .obj files.
There is a slight complication on Windows that you can have two classes of lib files.
Static lib files essentially contain a collection of .obj and are linked with your program to provide all the functions inside the .lib. They are mainly a convenience to save you having as many files to deal with.
There are also stub .lib which provide just the definitions of functions which are contained in a .dll file.
The .lib file is used at compile time to tell the compiler what to expect from the function, but the code is loaded at run time from the dll.
.lib files are "libraries" and contain "collections" of compiled code so-to-speak. So it is a way to provide software components, without giving away the internal source-code for example. They can be generated as "output" of a "build" just like executables are.
The specific contents depend on your platform / development environment, but they will contain symbols for the linker to "hook up" function-calls provided by e.g. the header-file of the library.
Some libraries are "dynamic" (.DLL's on Windows), which means the "hooking" of function-calls is setup when the executable using the library is loaded, allowing the library implementation to be changed without rebuilding the executable.
One last thing. You say you're learning C++, and a common confusing point is, that "symbols" generated by C++ compilers are "mangled" (in order to allow e.g. function overloading), and this "mangling" is not standardized across different compilers, so libraries often resort to C for the "API" of the library (just like OpenGL), even though the library may be implemented in C++ internally.
I hope shed some light on .lib-files. Happy OpenGL coding :-)
What exactly are library files in this
context used for?
They are compiled and linked code just like your executable. They're called static libraries that other programs can link to at compile time. In the case of OpenGL, you link to their libraries to build an executable that can run OpenGL code. Dynamic libraries (DLLs) are another type of library that executables link against, except at runtime.
What are their contents?
Static libs contain linked object code just like an exe. The *.obj files are the object code that the compiler generates for the linker.
How are they generated?
When the compiler creates the object files, it passes the work to the linker. You can create them in your development environment, just like executables.
Is there anything else worth knowing
about them?
Yeah, they're used everywhere, so it doesn't hurt to get used to them.