I was wondering if there was a way to create my own custom library , that would be visible for all future projects, and not just the current one ?
The library is supposed to be just a simple header file (.h) with all the libraries I need to work with already included in it. I've tried searching the web for a way to do it, but I had no luck in finding such a way. If anyone knows how to, it would be greatly appreciated. Thanks in advance.
In order to make your own library, you can follow these general steps;
Let's say you want to make a library mlib
First of all create an Interface of your library: mylib.h
Implement your library in mylib.c
Compile your c file and your will get object fiile with extention .o in linux that can be linked with programs that want to use our library code
Now you can include your header in your new program where you want to use your library and provide link of your object excuteable to compiler when compiling your program.
#include
// rest of your program
now for compiling
clang -o myprogram myprogram.c -lmylib
Related
I'm porting an old C++ project to run on RHEL 6.7 with gcc 4.4.7. The code was originally made to run on an SGI machine.
I have a library .a which is presumed to have been compiled on the old machine (and thus there's no hope of running it in the new one) however, along with this .a file I also have the headers and source files. I am assuming that these are the ones that are used to make the .a file. The Makefile that was used is now long gone, I just have the source code.
My question is, is there a way to "reverse engineer" the library? I would like to know what functions the .a library contains so I can make it on my machine.
I will add that I am new to static and shared libraries so I'm not entirely sure what the .a file contains or how it is any different from including the headers.
Update:
I have looked into the included code and realized that the C files only work to interface with functions defined using Fortran95. I think that now I'm supposed to build the Fortran95 codebase and somehow interface that with the C code. Once I do that I will have a library that should (hopefully) compile in my native system. How can I do this?
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
Why is it that some static libraries (lib*.a) can be linked in the same way that shared libraries (lib*.so) are linked (ld -l switch), but some can not?
I had always been taught that all libraries, static or not, can be linked with -l..., however I've run into one library so far (GLFW), which does nothing but spew "undefined reference" link errors if I attempt to link it this way.
According to the response on this question, the "proper" way to link static libraries is to include them directly, along with my own object files, rather than using -l. And, in the case of the GLFW library, this certainly solves the issue. But every other static library I'm using works just fine when linked with -l.
So:
What could cause this one library to not work when linked rather than included directly? If I knew the cause, maybe I could edit and recompile the library to fix the issue.
Is it true that you're not supposed to link static libraries the same way you link shared libraries? (And if not, why not?)
Is the linker still able to eliminate unused library functions from the output executable when the library is directly included in this way?
Thanks for the replies! Turns out the problem was due to link order. Apparently, if you use a library which in turn has other library dependencies, those other dependencies must be listed after the library, not before as I had been doing. Learned something new!
Have you cared to indicate to GCC the path of your library (using -L) ? By using -l solely, GCC will only be able to link libraries available in standard directories.
-L[path] -l[lib]
The correct way to link a static library is using -l, but that only works if the library can be found on the search path. If it's not then you can add the directory to the list using -L or name the file by name, as you say.
The same is true for shared libraries, actually, although they're more likely to be found, perhaps.
The reason is historical. The "ar" tool was original the file archive tool on PDP11 unix, though it was later replaced entirely by "tar" for that purpose. It stores files (object files, in this case) in a package. And there's a separate extension containing the symbol table for the linker to use. It's possible if you are manually managing files in the archive that the symbol table can get out of date.
The short answer is that you can use the "ranlib" tool on any archive to recreate the symbol table. Try that. More broadly, try to figure out where the corrupt libraries are coming from and fix that.
I am compiling a program in which a header file is defined in multiple places. Contents of each of the header file is different, though the variable names are the same internal members within the structures are different .
Now at the linking time it is picking up from a library file which belongs to a different header not the one which is used during compilation. Due to this I get an error at link time.
Since there are so many libraries with the same name I don't know which library is being picked up. I have lot of oems and other customized libraries which are part of this build.
I checked out the options in gcc which talks about selecting different library files to be included. But no where I am able to see an option which talks about which libraries are being picked up the linker.
If the linker is able to find more than one library file name, then which does the linker pick up is something which I am not able to understand. I don't want to specify any path, rather I want to understand how the linker is resolving the multiple libraries that it is able to locate. I tried putting -v option, but that doesn't list out the path from which the gcc picks up the library.
I am using gcc on linux.
Any help in this regard is highly appreciated.
Regards,
Chitra
Passing -Wl,-t to gcc will tell ld to dump which files it's reading.
I'm using Visual Studio .NET 2003, and I'm trying to port code I've written and compiled/run successfully in Linux GCC to Windows.
I'm a newbie when using VS. I've created a new project, and added all the .c and .h files I have into the project by Project -> Add Existing Items, then chose all the .c and .h files.
I'm not familiar with how exactly compilers and linkers etc work, but is there a difference between how VS and gcc compile/link #include files? My habit of programming in Linux has been to have one main.c file, and #include all other .h or .c files that I need. Then I would only compile the main.c file. But in VS, it seems as if the #include files are not "seen" by the program, because I'm getting errors that tell me certain structures or variables were not declared, even though they are in my user-defined header files.
I'm also getting errors like DIR is an undeclared identifier. I've included , so why can't it recognize DIR?
Thank you.
Regards,
Rayne
Consider compiling your program with windows port of gcc (from Mingw32 or Cygwin) first. This will provide you with more familiar environment. If you'll still have to compile everything with VC++, you'll have more incremental process of porting.
Also, it is not evident from your post, but it seems you are trying to use dirent.h. Note that dirent.h (and corresponding libs) is not included with VC++.
One of the best ways to learn would be to start with the smallest application that you can compile on both. Expand this working and portable application step by step into the more fully featured application you desire.
Remember to add all .c/.cpp files to the 'Source Files' directory in the project as they won't be compiled otherwise.
Restrict any non-portable code (that you will need) to a single place. For example if you need to create threads, have a common create thread function used throughout (but implemented differently). Using portable libraries such as Boost can help here.