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.
Related
I have compiled a simple Ada application which uses the Win32Ada library.
I'm compiling the application on Windows using:
gnatmake C:\GNAT\2020\bin\src\main.adb -I"C:\GNAT\2020\lib\win32ada" -largs -lwin32ada.
The application works as expected on the compilation machine and when executing main.exe a MessageBox is executed.
However, when attempting to execute the application on another Windows system which doesn't have the Ada libraries installed, I received an error:
Does Ada support static compilation?
Can I compile the application so main.exe can execute on any Windows host without needing to bundle DLL's?
I couldn't find an answer in the gnatmake --help (but I'm also new to Ada).
The default linking mode is static on Windows. So, normally, you don't need to add any option. If you need to force it, use the -bargs -static gnatmake binder option or add
package Binder is
for Default_Switches ("ada") use ("-static");
end Binder;
to your .gpr project file.
Does Ada support static compilation?
Yes, it's the default mode.
Can I compile the application so main.exe can execute on any Windows host without needing to bundle DLL's?
You should be able to, but I haven't used the win32ada library much; I would be surprised if you couldn't do something like Deplhi where the executable interfaces with the Win32 API "directly", albeit with the abstraction of the VCL.
I think the item you want to flag is in the Linker, not Binder. (Though you might need both.) The best place to check for the nitty-gritty of arguments for GNAT is the documentation, simply because there's a huge number of arguments which are essentially non-intuitive in their naming or usage.
--unchecked-shared-lib-imports might be of interest; checking out the win32ada project file (especially any scenario variables) might give you the ability to switch it to a static library. In the worst case, if you add For library_kind use "static"; to the Win32Ada library, you should be able to build it statically yourself.
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.
I'm writing a Go program that uses the GNU readline library for a fancy command line interface. In order to simplify the installing process and not worry about the library version and other stuff, I want to link it statically.
The problem is I don't really know how to do it. If I precompile the library, I would have to provide several versions of my code, with the different versions of the .a or .lib readline library. To avoid this problem I was thinking of just including the current readline code to my go project, and let the go tool compile it when it build the go project. However, to build the readline library, is necessary to use make. Is there a way of telling the go tool how to build the C code?
Yes, you can certainly do that. I've recently done something similar with a different project, mainly because the code was not available as a library (Ubuntu compiles just the command line tool for it). To achieve it, I've run the autoconf script with options that I figured would be sensible in most systems, and copied the C code together with the automatically built config.h header file into the Go package directory. Then, I've built the original C code with make once and observed which options gcc would get while compiling and linking it, and copied the appropriate ones into cgo's LDFLAGS and CFLAGS options (you can also inspect the Makefile, but that was easier).
A couple of side notes:
Have you considered doing the readline work in Go itself? The ssh terminal package works at least as a pretty good seed, if it doesn't solve your problem completely.
Remember that readline, although being a library, is GPL. You'll necessarily have to license your own software as GPL as well if you link or embed it. There are other smilar libraries available with less strict licenses, if you care.
I recommend avoiding readline, better alternatives exist; like https://github.com/edsrzf/fineline
I'm trying to build a project (namely, Angband's source - http://rephial.org/downloads/3.3/angband-v3.3.2.tar.gz) with Emscripten's emcc in order to port it to Javascript and ultimately build an online version.
I've managed to get the process started with
emconfigure ./configure
make
which begins to successfully start generating LLVM bitcode .o files, but then it hangs up on main-gcu.c with 'main-gcu.c:43:11: fatal error: 'ncurses.h' file not found'
I believe main-gcu.c is the only file that references ncurses, but I just can't figure out how to include the library while compiling. Is there a way to specify including ncurses with 'make', or should I compile the main-gcu.c file individually, with 'emcc main-gcu.c -c -lncurses'? I tried doing that but that led to another error with emcc being unable to find other actually included header files two levels down (it couldn't find headers that were included by a header included by main-gcu.c - anyway to fix that?).
I'm also not certain if I have/need to install the ncurses library on Mac OSX. All I can really find are references to libncurses5-dev for Linux.
Thanks!
I think you misunderstand the compilation via Emscripten. I will try to point out a few problems you are facing.
The general rule is that all tools of Emscripten ONLY can turn LLVM formats (e.g. BITCODE) into JavaScript. emconfigure, emmake, ... modify the build environment so that your sourcecode is compiled to one of the LLVM formats (there are exceptions to the rule but nevermind). So anything you want to link against your final result has to be in a LLVM format, as well (which by default ncurses is not).
Since the output is JavaScript, there is no chance to execute any program code in different threads. While a lot of C/C++ code does use a thread for the UI and others for processing, such a model does NOT work for Emscripten. So in order to get the software compiling/running you will have to rewrite the parts that use threading. See emscripten_set_main_loop for pointers.
Even if you have the libraries compiled you then have to statically link them to Emscripten. At this point it is less of a technical problem but more of a license issue since if your library is licensed under e.g. LGPL due to static linking the GPL terms are effective.
I hope all clarity finally vanished ;)
My question may be silly, but I need to use a library from its source code without compiling it to a library form first. The tool in question is FreeType. Is this possible?
You can add all the files from the FreeType source distribution into your own project, and try to get them to compile alongside. However, the FreeType compilation procedure is a bit tricky, if I recall correctly.
It is probably easier to compile FreeType as a static library, then link your own program with the generated library. If you do that, your executable will have no dependency on the FreeType runtime library.
It's called bundling: instead of shipping your code with JAR files of some library, or even just requiring the library in your INSTALL document, you simply copy the source code into your project and have it built by your build system instead of using it pre-built. It may require adapting your build system a bit, and you need to make sure you have the right to redistribute the library in source form, but it can sometimes make sense.
MPlayer did this with ffmpeg for a long time, and XEN with the Linux kernel (notionally, they ship patches instead of the entire kernel tree). The disadvantage is, of course, that you effectively fork the library, and don't get any updates of the code whatsoever unless you re-rip their code and get it to build in your project again.
You can get the sourcecode of FreeType from http://freetype.sourceforge.net if that's what you mean.