I am using msys2 to compile a library that uses autotools as the build system. The end result is a DLL. This DLL ends up referring to the following other DLLs that come with msys2:
libgcc_s_seh-1.dll
libstdc++-6.dll
libwinpthread-1.dll
How can I link these statically and eliminate these dependencies?
There are other questions dealing with this (example) and the solutions suggest using the options -static-libgcc -static-libstdc++. These work when linking an .exe, but they do not seem to work when linking a .dll.
I set the following variables before running ./configure (and checked the output to verify that these compiler options are really being used), but Dependency Walker still shows a dependency on libstdc++-6.dll, just as before.
export CFLAGS="-static-libgcc -static-libstdc++" CXXFLAGS="-static-libgcc -static-libstdc++" LDFLAGS="-static-libgcc -static-libstdc++"
(I assume these must only go in LDFLAGS, but since I don't have a full understanding, I also added them in CFLAGS and CXXFLAGS.)
Is there a way to get rid of these dependencies when linking a DLL, not an EXE?
The library is written in a mix of C and C++ and has a C API.
Try just using the -static option in LDFLAGs. I tested it just now in MSYS2 and it worked for me.
Related
I want to my make own library and have it use the same syntax as the standard C libraries as in
#include<mylib.h>
So that it looks like #include and some of the libraries that are included with C.
Can I make the library static as opposed to linking so that I can compile it in GCC without additional arguments, as if I were using another library like stdio.h or string.h?
This seems simple enough.
Develop the library (create as many source files as you need).
Build the source files into a shared library (.so) using a tool like CMAKE (which i strongly recommend).
Copy that library to your library path (i.e. /usr/lib)
Later on, all you have to do is import your lib: (i) in the source using #include<mylib.h>; (ii) when building (also using CMAKE) or using the flag (-lmylib) in the GCC compiler: gcc -lmylib myfiles.c -o myoutput.
In addition to #include "mylib.h", you need to add -lmylib command line to the compiler (more specifically linker) when using the library. I assume that the your library archive created through ar command is named as libmylib.a.
Usually, we do not write 'manually' build instructions, but we rely on tool that generates build chains. There are quite a lot of them, the most know are probably autotools and cmake (under Linux).
I would suggest you to have a look to cmake examples and/or documentation to get your code built.
There are quite a lot of differences between static and dynamic libs, and you will also need to package somehow your lib if you really want to use it like 'standard' lib (like libxml2, openssl, etc.)
A lot to say about it, but you should first have a look to 'how to build' your lib, and then see how to make it easy to use, IMHO.
I hope this is a basic question. I am trying to build a Go package which includes functions from a library written in C. The structure is basically as follows:
package too
/*
#cgo LDFLAGS: -L/usr/local/lib include -lbar
#include mybar.h
*/
import "C"
func MyGoWrapper () {
C.orig_func()
}
Running go build foo.go fails with an "undefined reference" for orig_func. Note that the header is mybar.h; I created a prototype for orig_func that was not included in the original library. Do I need to recompile the library first, including this header file, before it will link with the Go build? Or am I misunderstanding something else entirely?
When linking against an external library, you do need to separately compile it for your target architecture. cgo can't replace the configure/make (or whatever) to compile the library; it only knows how to build a few .c files in your package directory, and a library's build process might be more complex.
I'm less sure of how to accomplish the larger task of linking in an external library when cross-compiling (and I'm not sure what you've already done). The (closed) Go bug on cross-compilation with cgo looks useful here. You may want to build the Go toolchain with some environment variables set that are described in godoc cmd/cgo:
To enable cgo during cross compiling builds, set the CGO_ENABLED
environment variable to 1 when building the Go tools with make.bash.
Also, set CC_FOR_TARGET to the C cross compiler for the target. CC will
be used for compiling for the host.
After the Go tools are built, when running the go command, CC_FOR_TARGET
is ignored. The value of CC_FOR_TARGET when running make.bash is the
default compiler. However, you can set the environment variable CC, not
CC_FOR_TARGET, to control the compiler when running the go tool.
CXX_FOR_TARGET works in a similar way for C++ code.
The bug also mentions someone who uses -ldflags="-extld=$(CC)" (where $(CC) is the name of the cross-compiler they want to use).
In your example code there's an explicit -L/usr/local/lib and I don't think that'll work: I think when you build libraries for the target, you're going to want to put them in a directory distinct from the lib for your host arch. For example, this ARM cross-compilation HOWTO uses a /usr/local/arm-linux prefix or install_root in some places.
I am trying to modify the source code to an open source application on windows that uses mingw.
I am having a problem linking the psapi library.
psapi.h and libpsapi.a are in the mingw directory and I have tested it using the standard
gcc -o program program.c -lpsapi
method, and it works.
However, when I try to compile the program using the
./configure
make
method, it doesn't work I have tried,
./configure LDFLAGS=-lpsapi
make
and that doesn't work
and I tried going into the makefile.am and putting -lpsapi in AM_LDFLAGS but that doesn't work
The error it gives is just a standard "undefined reference to [function]", implying that the library with the functions is not linked
I have even tried putting psapi.h in the source directory and including it as #include "psapi.h" and that STILL didn't work.
LDFLAGS is the wrong one.
LIBS=-lpsapi should do the trick.
The order is important for the linker. The libraries (LIBS) have to come after the objects, LDFLAGS can be before.
How do I convince LibTools to generate a library identical to what gcc does automatically?
This works if I do things explicitly:
gcc -o libclique.dylib -shared disc.c phylip.c Slist.c clique.c
cp libclique.dylib [JavaTestDir]/libclique.dylib
But if I do:
Makefile libclique.la (which is what automake generates)
cp .libs/libclique.1.dylib [JavaTestDir]/libclique.dylib
Java finds the library but can't find the entry point.
I read the "How to create a shared library (.so) in an automake script?" thread and it helped a lot. I got the dylib created with a -shared flag (according to the generated Makefile). But when I try to use it from Java Native Access I get a "symbol not found" error.
Looking at the libclique.la that is generated by Makefile it doesn't seem to have any critical information in it, just looks to be link overloads and moving things around for the convenience of subsequent C/C++ compiler steps (which I don't have), so I would expect libclique.1.dylib to be a functioning dynamic library.
I'm guessing that is where I'm going wrong, but, given that JNA links directly to a dylib and is not compiled with it (per the example in the discussion cited above), it seems all the subsequent compilation steps described in the LibTools manual are moot.
Note: I'm testing on a Mac, but I'm going to have to do this on Windows and Linux machines also, which is why I'm trying to put this into Automake.
Note2: I'm using Eclipse for my Java development and, yes, I did import the dylib.
Thanks
You should be building a plugin and in particular pass
libclique_la_LDFLAGS = -avoid-version -module -shared -export-dynamic
This way you tell libtool you want a dynamically loadable module rather than a shared library (which for ELF are the same thing, but for Mach-O are not.)
I am getting linking error when I try to compile a test code.
I'm using cygwin on windows 7.
Initial steps like ./configure, make, make test & make install went fine
I'm also able to generate .pb.cc and .pb.h with protoc command.
But when I try to compile my test code, it gets many linking errors. I'm sure those errors are because it is unable to link to library.
Cygwin has protobuf static library and linking library in /usr/local/lib
. include files are present in /usr/local/include
I tried with -lprotobuf, but it returns error saying -lprotobuf not found
It hard to say what the problem is since you don't include neither the makefile nor the errors, but my guess is that the path /usr/local/lib is not included in the search path when looking for libraries.
Try adding -L/usr/local/lib before -lprotobuf.