Using -buildmode=archive produces mylib.a. I'm not fully understanding the steps required to then use this library in another Go program.
I've tried instead generating -buildmode=c-archive which produces a header file and archive, but the headerfile is not designed to be imported using cgo (there is conflicts with imported types).
Research online has yielded the conclusion that -buildmode=c-archive is specifically not designed for cgo use for this reason.
My query is what is -buildmode=archive actually used for if it cannot be included?
I'm not fully understanding the steps required to then use this library in another Go program.
It can be tricky. Need to look into each compiler toolchain for linking them correctly, i.e. gcc/clang etc. and find how, and if it's even possible to link them and use them.
What is -buildmode=archive actually used for if it cannot be included?
From the docs: https://pkg.go.dev/cmd/go
-buildmode=archive
Build the listed non-main packages into .a files. Packages named
main are ignored.
That's what it does, what you do with it, it's up to you, there's tons of information online, for example: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
Related
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.
We have a software project which has the primary purpose of providing a library and API. We also provide example programs and utilities that use this library.
So, let's say that I have built and installed our library. When I run valgrind on one of the example / utility programs, I obviously see references to functions in the library. The issue is that it doesn't provide line numbers, and I would like it to.
Is there a way to tell Valgrind to reference source files that aren't obviously part of an executable, but are part of the source code for a library that is linked-in to the executable?
Thanks!
Make sure that you are compiling shared library with -g to add debug information. This should be enough for Valgrind to reference source files. See http://valgrind.org/docs/manual/faq.html#faq.unhelpful for more information.
I have C project of a library (using CDT). Configurations for both static and dynamic linking for several platforms. Several examples of the library usage is also included in the project. What is the best way to build these examples with the library? If I would like to build both the library and examples (linking the library just built) in one configuration?
I suppose I have to use custom makefile. Do I have to create makefile for the whole project (several of them, one for each platform), or is there any way how to include examples makefile to the automatic one?
Each example has only one source file, so the only things I need to do in my makefile are to determine which compiler is used, add some flags and link with the library which was built (I would include the make examples command as the post-build step).
As I didn't find any solution for this, I use custom makefile for the whole build. I also found a nice advice somewhere: if you want advanced build functions, use advanced build system.
I'm trying to understand the way a particular package fits into a project I'm working on. I believe only a portion of this package actually makes it into the binary of the project, and I need to find out exactly which parts. Library functions from this package are called from many other places (i.e. several other packages depend on it).
I plan to build the project and distribute it. Is the only way to determine which source->binary files I'll distribute by looking at all of the headers in my dependent packages? Or is there a more clever way to approach this?
Thanks in advance,
You haven't given us much information to go on, but here's a method that will work: remove parts of the package and see if the project will still compile.
Use nm to unpack a static lib. This will list all the files and methods included in the lib.
You could also try using strings.
This displays strings that are defined in the binary.
Look through your source and see if the strings you define are in the library.
Something like gprof could also be used to see which methods are called by your executable.
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.