Dependency Libraries: libxml >= 2.7.6 openssl >= 0.9.8 Digital Signature Generation requires an additional libraries: libXslt >= 1.1.24 libxmlsec1 >= 1.2.9
These are Dependency library. i have project code but for running the makefile required dependency libraries.
I have downloaded these libraries and copy into usr/include folder then installed.
but i dont know the exact way how to add in makefile these dependency library...
i m using ubuntu 11.04.
#GCC compiler
CC=gcc
CFLAGS= -D__XMLSEC_FUNCTION__=__FUNCTION__ -DXMLSEC_NO_XSLT=1 -DXMLSEC_NO_XKMS=1 -I/usr/include/libxml2 -DXMLSEC_CRYPTO_DYNAMIC_LOADING=1 -DXMLSEC_CRYPTO=\"openssl\" -DUNIX_SOCKETS -DXML_SECURITY -DDEBUG -I/usr/include/protobuf-c-0.15 -L/usr/include/libxslt-1.1.24
LDFLAGS= -lcrypto -I/usr/include/libxml2 -lxml2 -I/usr/include/xmlsec1 -lxmlsec1 -lprotobuf-c
LIBS=-lm
fileClient:
$(CC) $(CFLAGS) $(LDFLAGS) $(LIBS) src/main.c src/file2.c src/file3.pb-c.c -o fileClient
clean:
$(RM) fileClient *.o *~
#
Don't do that in the Makefile but in some of your header with code like
#if LIXML_VERSION < 20800
#error too old version of libxml need 2.8.0 or newer
#endif
and you may be interested in autotools (autoconf, automake and friends) and in pkg-config
Also, dependency management is best handled by making a .deb package. (so you want an Ubuntu package like libxml2-dev)
Related
I've been having trouble compiling an executable with SDL 1.2 and C that will work on another machine. I'vee been compiling it from Ubuntu using a makefile. I'd like to be able to send a "bin.zip" to a classmate, with "SDL.dll" and "SDL_ttf.dll" inside as well as "prog" the executable that I compiled for them.
I would expect them to be able to run that "prog" from their own Ubuntu desktop (Virtual Machine, if that's relevant) and not need to install libsdl1.2debian and libsdl-ttf2.0-0 themselves first, since I included the DLLs.
Note that they can run it fine once they've installed those libraries.
My project structure, at compilation, is such:
2048-c
/bin (dlls and executable)
/include (".h" header files)
/lib ("SDL.lib", "SDL_ttf.lib", "SDLmain.lib")
/src (".c" source files)
"makefile"
My makefile looks like this:
CC=gcc
CFLAGS=-c -Wall `sdl-config --cflags`
LDFLAGS=`sdl-config --libs` -lSDL_ttf
SOURCES=src/main.c src/toolbox.c src/game.c
OBJECTS=$(SOURCES:.c=.o)
EXECUTABLE=bin/prog
.PHONY: clean
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(CC) $(OBJECTS) $(LDFLAGS) -o $#
.c.o:
$(CC) $(CFLAGS) $< -o $#
clean:
rm -f $(OBJECTS) $(EXECUTABLE)
Am I missing something obvious? Edit: (Yes, I was)
Yes, I was missing something obvious : DLLs are specifically for Windows
Now, as for getting an executable to work without installing the required libraries, I still haven't managed that (linking statically didn't pan out, in my case), but at least I learnt something.
If I give cross-compilation to Windows a try, I'll try to update this.
I am building a Swift command-line application with references to a third party library (netcdf) in /usr/local/lib. I have a bridging header in the project and when making the appropriate calls, there are no errors. So I'm fairly confident that the #include is being found in the bridging file.
In Build Settings, I have added /usr/local/lib to Library Search Paths and -lnetcdf to Other Linker Flags.
However I am seeing a link failure. Specifically I am seeing an undefined symbols message. Looking at the ld command shown when I click on the error, I can see that -L/usr/local/lib is there. However the -lnetcdf is not.
What else do I have to do to get the -l into the link command?
After three hours of trying to resolve this, I eventually thought 'stuff it' and spent about 15 mins writing a Makefile.
CLIBS=-lnetcdf
SWFILES=main.swift NCUtil.swift
SWIMPORT=-import-objc-header ../GSIP-Bridging-Header.h
SWIFTLIB=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx
SLIBS=-lSystem -lobjc
GSIP: main.o NCUtil.o
ld $^ -arch x86_64 -L $(SWIFTLIB) $(SLIBS) $(CLIBS) -rpath $(SWIFTLIB) -macosx_version_min 10.10 -no_objc_category_merging -o $#
%.o: %.swift
swiftc -c $(SWFILES) -target x86_64-apple-darwin14.5.0 -I /usr/local/include -I /usr/include $(SWIMPORT) -module-name=GSIP
.PHONY: clean
clean:
rm -f *.o GSIP
There is in fact another solution. Using the Finder menu to Go -> Go to Folder, go to the directory where the dylib is located. Then from Finder, drop and drag the dylib into your project. Probably a wise idea to use a reference rather than make a copy of the file.
This resolved all my link errors!
I'm trying to link libc.a library but always get cannot find -llibc. Library is in project lib folder. Below is my linker settings and workspace sreenshots.
Full compilation string:
arm-none-eabi-gcc -L"/home/kripton/Applications/ARM_workspace/Bell/lib" -T "/home/kripton/Applications/ARM_workspace/Bell/stm32f103.ld" -g3 -ggdb -O0 -mthumb -mcpu=cortex-m3 -mfix-cortex-m3-ldrd -Wl,-Map=linker.map -Wl,-cref -Wl,--gc-sections -o "Bell.elf" ./stm_startup/startup_stm32f10x_md.o ./stm_startup/system_stm32f10x.o ./src/main.o ./src/syscalls.o ./cmsis_core/core_cm3.o -llibc
Linker libraries settings:
As I said libc.a placed in project lib directory.
UPDATE
Problem solved by manually installing newlib and replace all sources and libraries with new.
I've made a C program that uses libsndfile to extract some data from audio files.
What possibilities are there to make the program as portable as possible, preferably without requiring root access when installing?
Libsndfile is not available at the target machines, so i need to somehow package it with my program. Is there a way to statically link the library? I've also looked at some Autotools tutorials, but I'm not sure how to proceed.
I can compile without a hitch on my dev machine, where I installed the libraries using the package manager: apt-get install libsnfile1-dev
The makefile is very simple:
CFLAGS=-std=c99 -Wall -pedantic -g
CLIBS= -lsndfile -lm
BIN=audiodecode
CC=gcc
MAIN=main.o
FILES=
OBJS=$(FILES) $(MAIN)
.PHONY: all
all: clean $(OBJS)
$(CC) $(CFLAGS) -o $(BIN) $(OBJS) $(CLIBS)
.PHONY: clean
clean:
rm -f *.o $(BIN)
A lot of packages bundle their dependencies. Examples: rsync (contains a bundled libpopt), gnupg (contains a bundled libz). Other dependencies commonly bundled are gettext or glib.
For inspiration look at how these popular open source projects do it.
Put the content of http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.25.tar.gz into a subdir and add apropriate rules to build the the subdir first.
Untested sample code:
OBJS += libsndfile/libsndfile.a
libsndfile/libsndfile.a:
cd libsdndfile && ./configure --enable-static && $(MAKE)
For Bonus points add a configure script, that check if the system has already installed libsndfile and link to it dynamically.
This is my make file
EXE = signsrch
CFLAGS += -s -O2
PREFIX = /usr/local
BINDIR = $(PREFIX)/bin
SRC = $(EXE).c
all:
$(CC) $(CFLAGS) -c disasm.c
$(CC) $(CFLAGS) -c asmserv.c
$(CC) $(SRC) $(CFLAGS) -o $(EXE) *.o
install:
install -m 755 -d $(BINDIR)
install -m 755 $(EXE) $(BINDIR)/$(EXE)
.PHONY:
install
I want to cross compile it for my ubuntu and I tried:
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
but I get unknown type name errors with a bunch of âDWORDâ
Help?
We also need to see some code, but....
Windows has its own types for basic things above the vanilla C ones, as does Linux. It sounds like DWORD as a type is not known in Linux (likely). You'll probably have to create a mytypes.h file that redefines Windows standards like DWORD into Linux speak when building for a Linux platform. Linux has types.h that defines things like int32_t which is the equivalent. See this thread for more about this.
I've assumed you have a working cross compiler set up and you're fighting just with the port. If you haven't, that's your first job. You could have a windows based compiler that targets Linux (the cygwin option, mentioned in another post) or go for a Linux based compiler and targetting windows (crosstool will help here). Though since you seem to be targetting arm, I'm expecting that that Ubuntu install isn't the place you wish to build! :-)
to cross compile you need a toolchain for the target platform, not just a Makefile. Check this tutorial and also Cygwin