You'll have to forgive me as I'm a bit new at C development. I'm working through the awesome guide found at c.learncodethehardway.com, so bear with me.
I'm trying to write a simple program which uses libbson to read and write a BSON tree to and from disk. In the past, I've usually just done apt-get install openssl-dev or the like to install headers on my system, but libbson is kind of new and doesn't exist in a deb form yet. Plus, I'd like my project to ship with it statically compiled-in for now until it becomes more widely available.
I know fairly basic things like the general format of a Makefile and how to write fairly simple stuff in C. How and where would I include the source code of libbson into my project to by statically compiled into my executables?
(Using gcc and would like to encapsulate compilation into a Makefile)
gcc -static your_program.c -L ./LIB -lbson -o your_program
where libbson is stored inside ./LIB.
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 am working on a project that uses C and Haskell. Currently, I am using CMake to build a C shared library and cabal to build a Haskell executable. Is there a more unified way to do this? Can I invoke cabal from the Makefile generated by CMake or is there a way to build the C library directly from Cabal? Thanks.
CMake could also do what you want. It does however duplicate lots of the functionality of cabal. So you could call cabal from whatever build tool you choose to use (for cmake, using a custom command, for makefiles, it's pretty self-explanatory), build binaries directly (see cabal build -v).
See Is it possible to use cmake for Haskell projects?.
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.)
Let me start out by saying that I'm not a C developer and I know very little about actually writing real world C code. I've been doing some research to find a xUnit framework that I can use to write tests for C code and based on what I've found it seems like Unity is the one that I want to go with. It seems simple enough, but I really just don't know what to do after I download the zip file from Unity's website. It doesn't seem to have the normal configure/make/make install, and if it did, I'm not sure that is what I should be using anyway. It does, however, ship with some rake tasks, but none of those seemed to be any kind of "install" task. As a last resort I tried to just copy the 3 source files in with my code (which I really hope is not the right thing to do), but when I try that I get an error trying to compile my c file with gcc, but I think this should be working. Here is my set up:
src/
mycode.c
unity.c
unity.h
unity_internals.h
Here is the source for mycode.c
/* mycode.c */
#include "unity.h"
void test_sample(void)
{
TEST_ASSERT_EQUAL_INT(0, 0);
}
When I run gcc mycode.c I get:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"_UnityAssertEqualNumber", referenced from:
_test_sample in ccyHByv6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(I get a similar error when I try to compile unity.c with gcc). Which I assume means that the code that ships with unity requires a different compiler than what I have which is:
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
or that maybe unity is not compatible with a 64 bit processor... (I'm running on Mac OS 10.7.3 with a 2.4 GHz Intel Core 2 Duo processor - another thing that may or may not be relavent is that I've got XCode Version 4.3 (4E109) and also Command Line Tools for XCode) At this point I'm just grasping at straws and I'm in way over my head.
My question is, what is the correct process to go through to take a 3rd party C library, such as Unity, and make it available to my C code? Do I need to install something like in Python or Ruby or add something to my path like in Java or something else? Shouldn't just dropping unity's code in with mine work? Am I doing something wrong or is Unity or both? I really just want to be able to test drive C code using Unity. Any help would be greatly appreciated. Thanks in advance!
First, try 'gcc *.c -o mytest'. This will compile all of the C source files into object files, and then link them together into the binary 'mytest'. Keep in mind that all C source files have to be compiled to object files before they can be linked together. (A library is just a bunch of packaged object files.)
If you had a unity library installed in /usr/lib, you could do something like 'gcc mycode.c -lunity -o mytest'. If you had a unity library sitting in the current directory, you might do 'gcc mycode.c ./unity.a -o mytest'. This tells the compiler to look for a file named 'unity.a' in the current directory. Some libraries build .so files ('shared object' files, similar to DLLs in Windows). Replacing 'unity.a' with 'unity.so' should work if that is the case. (I'm assuming a Unix/Linux environment here.)
As an alternative to Unity, look at Google Test, which can be used with C code. I know it is supported on the Mac as well. The primary benefit is a large and active community. More information on Google Test from another SO question: Is Google Test OK for testing C code?
I figured out my problem. It turns out that unity requires you to define a setup and a teardown function and if you do not, you will get errors similar to the one that I was running into.
I am just looking for some guidelines, as this might seem like a very open question.
I have a project that has been compiled using Visual Studio 2008 sp1. I have to compile so it will run linux using gcc 4.4.1 C99.
It is a demo application that I didn't write myself.
The source code is written so it can be cross-platform (linux, windows), so the code will compile and run on linux. However, has it has been developed using VS, I don't have any makefile to use.
I could write a make file. But I am not sure about the dependences as there are about 20 files all together (*.c and *.h).
I am just wondering how can I write a makefile from a visual studio project? Is there any settings I can use? and what depends on what? Anything else?
Many thanks for any suggestions,
The makedepend utility will scan the C files you give it, using C preprocessing rules to determine their dependencies and output them to a Makefile.
This should do most of what you want.
One tool that you can use is CMake. CMake can generate a VS.net solution file, and it can generate a Unix makefile. This way is not easy, nor is it the without its bumps in the road. (Especially when the build sequence gets complex)
Start with a very simple Makefile:
theapp: *.c *.h Makefile
gcc *.c -o theapp
Those two lines will get you 90% of the way there (and, in a lot of cases, 100% of the way).
Now you can make and run your app in Unix simply with:
$ make && ./theapp
I don't recommend that you use those complex Makefile generators like automake unless you plan on releasing this stuff to the world.
For private projects, keep your makefiles simple and clean.