I recently received a closed-source SDK consisting of a C header file (.h), a library file (.lib), and a dynamic library (.dll). They were compiled using Microsoft's Visual C++. However, I am attempting to write my code using MinGW (GCC ported to Windows, for anyone unfamiliar with the project). It appears that ld is unable to link to the .lib file. I was wondering if it was possible to write a compatibility wrapper between the VS-compiled code and the GCC code I'm writing.
Is there an ABI mismatch or does it just not want to to link against the object format? If it's just a linking problem, you can extract the functions you care about, disassemble them, and then reassemble them into an object your linker can handle. Even easier, maybe objcopy(1) can speak both formats and can help you out?
If you do have an ABI problem to deal with, you can do the same but also add a shim layer to thunk the ABI so that the function calls will work. How complicated that layer is and how difficult it will be to write will depend on the interfaces of the functions you're trying to use.
Don't get too discouraged by the comments - it's software, so pretty much anything is possible.
Related
I need to extract source code for a function from the existing C library (the library is open source). The problem is that functions are created using macros in header files, and when I write a test project and link the library to it the debugger points me to that header file on 'go to definition' action. I have the source code of the library and I guess i need to build it together with my test code (maybe this is not correct, I am not sure). Any advice on how to proceed, what to use? Thank you.
I need to extract source code for a function from the existing C library (the library is open source).
Several C compilers are themselves open source. Both GCC and Clang are (and so is tinycc). So you legally could improve them (but that could take months of work).
In addition, recent GCC versions (e.g. in july 2020, GCC 10) accept plugins. Your GCC plugin could work on some internal GCC representations (e.g. GIMPLE, GENERIC) so will know about functions (even obtained by preprocessor expansion).
You could also consider using some open source static program analyzers, such as Frama-C or Clang static analyzer.
PS. Take into account open source license issues (legal ones). I am not a lawyer (and you might need to ask one, if you mix various software of different open source licenses).
I'm attempting to compile a sample c file that was given to me, but unfortunately, it's missing several libraries as some of the include files cannot find them. Namely: stropts.h, netdb.h, sys/socket.h, sys/ioctl.h, netinet/in.h, pthread.h, and unistd.h.
I've researched where I could fix these problems, but surprisingly there have been little to no results on this problem strangely. The Visual Studio command prompt isn't able to compile it until I can find these libraries. Anything I need to download/ link to fix this?
Those header files are not part of standard C or C++. Do not attempt to download the headers from other sources; even if you can get them to compile, they won't link properly since you don't have the implementations of the functions declared therein in a static library or DLL.
The simple fact of the matter is that the code you're trying to compile was written for Unix/Unix-like systems and it's not portable to Windows. You'll need to either significantly rewrite the code to use the equivalent Windows functionality or a 3rd-party platform-independent library (e.g. Winsock or Boost sockets for sockets), compile it on a Unix system (you could use a virtual machine if you want), or use a Unix compatibility layer such as Cygwin.
I have implemented semaphores in Linux last year. But for that I have to use -lpthread.
Now while implementing log10() function in C, I surfed the INTERNET and I saw that I have to use -lm.
I want to know why these kind of command line arguments are necessary in Linux.And Does this rule is compiler oriented?
(In windows Turboc compiler, I never used these kind of arguments.)
You are instructing the compiler to look for certain libraries and use them to try and produce a final object file.
When you were doing your threading code, you used threading primitives. These threading primitives are implemented in a library called pthread, -lpthread tells the linker to use the library pthread, without providing this switch the compiler will not be able to produce a valid object file as it is missing threading code implementation.
On the file system the libraries can be found in /usr/lib and lib (among others) when you look in these directories you will see files start with the lib prefix. for example libpthreadxxxxxx. You will have to do your own research to figure out what the xxxx means.
The development cycle using unix style tools is very granular on the surface, when you use heavyweight IDE's (read: visual studiio for C++), the IDE implicetly links against loads of standard libraries, so often you do not need to supply the name of the libraries you will commonly use. However, when you start doing more advanced programming you will probably have to install and configure your IDE to use external code libraries. If you were to use threading primitives in visual studio, you most likely will not have to provide the compiler with information on where to look for threading primitives, Microsoft considers this a common library and every new project will implicitly link against it.
A little discussion on GCC
GCC is a very diverse compiler producing code for various different usage scenarios. As such they try to be neutral and do not make assumptions. For example pthread is a particular threading primitives implementation. However, even through now on Linux at least it is the defacto standard, it is not the only one. Other Unix implementation have had different implementation. When such choices exist it is not fair for the compiler developers to implicitly link against libraries. They do however implicitly link against standard libraries; for example G++ is just a wrapper command to the internal compiler code, it is a C++ front-end so it implicitly links against an implementation of the C++ standard library. Similarly the C front end links against a the standard C library.
People often do not want to use certain standard library implementation, and instead they might want to use another implementation, in such cases you have to explicetly inform the compiler to use an implementation that you provide. Such use cases are very granular and are surface level issues with G++. In visual studio, you would have to tinker a lot to make such changes generally, since it is not an anticipated use-case anymore.
wikipedia will provide you with more information.
Edit: I'll fix the spelling and Grammatical issues later :D
The option -l indicates to gcc what libraries must be used for linking. -lpthread stands for "use the pthread library", and -lm stands for "use the m library" which is the math library. These commands are relative to gcc, not linux.
Because by default, gcc only links the C library (libc), which contains the well-known functions printf, scanf, and many more.
log10 exists in a different library called libm, and thus you need to explictly tell gcc to link that library, with -lm. The same logic applies for -lpthread.
This is purely a backwards, harmful practice. Separating parts of the standard library into separate .so files does nothing but increase load time and memory usage. Good luck getting anyone to change it though... Just accept that you have to do it (and that POSIX specifically allows, but does not require, that an implementation require -lm for using the math functions and -lpthread for using threads, etc.) and move on to more important things.
Or, go pester Drepper about it on the glibc bug tracker/mailing list. He won't change his mind, but if you enjoy flamewars you can get some kicks...
I'm trying to use an API for a proprietary interface device on an embedded system (Freescale HCS08), and the provided files include headers (.h) and libraries (.lib). The header compiles fine with the rest of my code (standard C), but when trying to link against the library I get memory errors saying the file might be corrupted.
My understanding of libraries in C is somewhat limited as I work almost exclusively on embedded systems where magic things like stdio, files, and dlls don't exist; but would the (or any) library be platform specific? Does it contain fully (if there is any sort of level there) compiled code? Some of the other files provided are VS project files, so if it is the case that the .lib is platform-specific, it wouldn't be unexpected that linking a file meant for x86-Windows to an 8-bit compiler would fail; it could be just me.
Not only is a .lib file CPU specific (there would be no way to link HCS08 code to x86 code), it is toolchain specific (CodeWarrior won't talk to SDCC, GCC/binutils won't talk to Visual Studio).
Yes the .lib contains compiled code so it is platform-specific. If you have the source you should be able to re-compile it to your platform.
I compiled libxml2 with BCC 5.5 command line compiler, now I have lots of .obj files which I'd like to link into my Delphi application. Unfortunately, I get lots of "Unsatisfied forward or external declaration" errors, pointing to standard C library functions like memcpy, open, recv etc ...
What should I do to compile it correctly? I'd like to avoid depending on msvcrt.dll or any other external libraries.
Thanks in advance!
Depending on the version of Delphi you have, there should be a unit called crtl.dcu with which you can link. Just use the $L directive for each .obj file in a unit that also uses crtl. You may also need to "use" other various units like Windows, WinSock, etc... The point is to provide the symbols and functions to resolve during the link phase.
This is the same technique used to statically link in the DataSnap TClientDataSet code used to also build midas.dll.
you should read article of Rudy here "Using C object files in Delphi"
Don't use those functions, but rewrite them to call operating system functions (kernel32/system32) directly.