I am experimenting with Apache module development and therefore I'd like to know how to link a static library to a module (if it is even possible).
Naturally it compiles and installs nicely and Apache fails when the module is loaded. The message is:
Cannot load /usr/lib/apache2/modules/mod_example.so into server: /usr/lib/apache2/modules/mod_example.so: undefined symbol: zmq_socket
The library I want to link is zeromq, I am using the makefile generated by apxs2. Here I added -lzmq. If I remove zmq related code, the module runs fine.
My platform is Ubuntu 12.04 64 bit, gcc4.6.3.
well, apparently the generated makefile is not a good idea. I replaced the makefile references with basic compilation commands, e.g.:
apxs2 -c -lzmq mod_example.c
alk's suggestion in the comment of the question would also work (adding library location to LD_LIBRARY_PATH), since I was linking another apache-related library (apreq), which linked without any problems.
Related
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.
I am a relatively inexperienced C developer with no previous experience in integrating libraries made by other developers into existing projects.
Basically, I need a means of parsing JSON data in an AVR microcontroller for a university project. To this end I attempted to download and integrate jansson (https://github.com/akheron/jansson) into my existing build of the microcontroller code. I am working with Atmel Studio in Windows 10, but I have also installed Code::Blocks with MinGW GCC (on the same Windows 10 installation) for the purpose of building the library, and to attempt to integrate the library into a native Windows application. So far, neither has been successful, and I get the same errors. All of the online resources I've found so far have been to basic to be useful, or well beyond my comprehension.
This is what I have done thus far:
I began by attempting to build the software and then integrate it into an existing project per the instructions in https://jansson.readthedocs.io/en/2.11/gettingstarted.html. I installed CMake, built the project files for Code::Blocks with cmake.exe -G “CodeBlocks - MinGW Makefiles”, then opened the project and built everything. A few of the targets (I believe related to testing) failed to build, but jansson itself built and output libjansson.a to the \lib\ directory, so I didn’t think too much of it.
That is as far as I’ve been able to get. In both Atmel Studio and Code::Blocks, I do the same thing: add jansson.h to the relevant include paths, add #include “jansson.h” to all of the relevant files, and add libjansson.a as a library in each IDE’s respective linker options. I’ve tried various things like adding and removing flags to the linker, but the output is always “cannot find -ljansson”, “undefined reference to ‘json_object_seed’” (which is a function in the API I’m calling for no reason other than to see if the project has built properly) and/or “ld returned 1 exit status”.
I cannot help but feel as if the issue is with the line “cc -o prog prog.c -ljansson” in the documentation linked above. I really just don’t understand how to set up the linker properly to get the project to build.
If anyone could give some insight into what I’m doing wrong/the correct way to link this library I would appreciate it a lot.
The library itself should be built with appropriate toolchain. I assume that you built your library twice, one version using MinGW toolchain and other with avr-gcc toolchain.
If you compile target application and linker cannot find library, then try to add path of directory that contains *.a file of library to linker settings (linker search path). Let's say you have: /path/to/lib/libjansson.a
In Code::Blocks: Project → Build options → Search directories → Linker add /path/to/lib/. Then it should link with include path set, for example: cc -o prog prog.c -ljansson -L/path/to/lib/
In Atmel Studio when you add a library in Solution Explorer → Libraries → Add Library it should automatically add library search path to linker options. If you check Project → Properties → AVR/GNU Linker there should be (between other options): -Wl,-ljansson -Wl,-L"/path/to/lib/"
If you copied library files (libjansson.a and jansson.h) to your application's project directory, it will be convenient to use relative paths to library files.
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.
Playing around with this a bit, but not getting too far...
The logic of my SQLite code works if I compile it as a stand-alone executable.
My mod_hello.c compiles and loads/works fine without the SQLite code
Combining the two, the module compiles and is installed, but the apache process dies immediately every time it is loaded. Stripping out all the SQLite code and simply linking against SQLite causes this problem. In other words, with the same code:
apxs -cia -L/usr/local/lib -I/home/devin mod_hello.c
/* Works Fine, prints "hello world" */
apxs -cia -L/usr/local/lib -I/home/devin -lsqlite3 mod_hello.c
/* compiles but dies on apache load */
The platform is OpenBSD 4.6 with the platform's version of Apache 1.3 and SQLite 3.6.20 downloaded from the SQLite site and compiled from source
The problem had to do with my downloading SQLite and compiling - when I deleted all those resulting files and installed the OpenBSD package for SQLite, it worked fine. So there must be some platform-specific compile tweaks needed for the SQLite library. Best to use the packages I guess.
-- devin
Normally when this happens, either libsqlite3.so isn't in LD_ LIBRARY_PATH, or libsqlite3.so isn't quite what you want to link to, i.e. there's e.g. libsqlite3.1.so that you want to link to. So my advice is to check the load-time paths, to make sure libsqlite3.so is there, and to check if there's a libsqlite3.x.so somewhere that you may need to link to instead. (-lsqlite3.x instead of -lsqlite3