I have a project that builds with
autoreconf --install
./configure
make
and contains configure.ac and Makefile.am
The project builds 2 libraries and one executable that dynamically links them. One library is cpp, other and the executable are pure C. I want to link one of the libs (cpp one) statically and keep c library to link dynamically. My simplified Makefile.am is
ACLOCAL_AMFLAGS = -I m4
SUBDIRS = include doc po
AM_CPPFLAGS = -Iinclude
AM_CPPFLAGS += -D__STRICT_ANSI__
AM_CPPFLAGS += -DNDEBUG
WARNFLAGS = -Wall
AM_CFLAGS = $(WARNFLAGS) $(OPENMP_CXXFLAGS) -std=c11
AM_CXXFLAGS = $(WARNFLAGS) -std=c++11
localedir = $(datadir)/locale
DEFS = -DLOCALEDIR=\"$(localedir)\" #DEFS#
lib_LTLIBRARIES = libmy.la libmy-settings.la
libmy_la_SOURCES = src/sharedlib.c src/sharedlib.h
libmy_settings_la_SOURCES = src/staticlib.cpp src/staticlib.h
bin_PROGRAMS = myapp
myapp_SOURCES = myapp.c
myapp_LDADD = libmy.la libmy-settings.la
The libtool generates both .a and .so files in ./.libs/ but Libtool prefers .so. In the last make command I see gcc -Wall -std=c11 -g -O2 -o .libs/myapp myapp.o ./.libs/libmy.so ./.libs/libmy-settings.so. If I replace it with gcc -Wall -std=c11 -g -O2 -o .libs/myapp myapp.o ./.libs/libmy.so ./.libs/libmy-settings.a - it works and gives me that I'm trying to achieve. The question is: how to achieve it automatically wit help of Makefile.am?
As I understand, I can't just add myapp_LDFLAGS=-lmy-settings.a bcs it won't replace shared linking argument but add a new one. And I can't remove the libmy-settings.la from lib_LTLIBRARIES or myapp_LDADD bcs it won't generate libmy-settings.a or libmysettings.so in ./.libs/ at all. Any clues?
Since libmy-settings does not need to be a separately installable library, you have two pretty straightfoward alternatives:
Add its sources to myapp_SOURCES, and leave libmy-settings.la completely out of the picture. That the additional sources are located in a different directory and written in a different (autotools-supported) language should not be a problem. This approach may be to your advantage in terms of the Autotools choosing the correct linker driver and options without your intervention, too.
Build libmy-settings.la as a utility library instead of an installable one. This is achieved by marking it noinst:
lib_LTLIBRARIES = libmy.la
noinst_LTLIBRARIES = libmy-settings.la
Related
I have this very simple makefile:
P = hello_world.exe
OBJECTS = main.o
CFLAGS = -g -Wall -O3
LDLIBS =
CC = clang
$(P): $(OBJECTS)
When I run make it will compile main.c but it will not link to hello_world.exe. Shouldn't that be happening automatically?
My environment is cygwin 64bit.
The output of make -p is here: http://pastebin.com/qbr0sRXL
There's no default rule for .exe files that I'm aware of (or can find in that output).
You'll need to write one yourself.
If your output was hello_world and you had a hello_world.c/hello_world.cpp source file and also a main.c/main.cpp file then your makefile as written would work I believe (since the default %: %.o rule would apply and your added prerequisite would be added to the hello_world prerequisite list).
I am trying to install QCL-0.6.4 from this source, but I keep getting errors, when I try it with the make command in the terminal.
I came along this thread about installing QCL on OSX, but when trying to adjust the Makefile I always come across this errors:
extern.cc:84:18: error: variable length array of non-POD element type 'tComplex'
(aka 'complex<double>')
tComplex u[dim][dim];
^
extern.cc:193:9: error: variable length array of non-POD element type 'term'
term t[dim];
^
extern.cc:224:9: error: variable length array of non-POD element type 'term'
term t[dim];
Any help on this would be highly appreciated.
There are a few issues at play here which you need to overcome to get this compiling on OSX. My instructions below assume that you are running on El Capitan (10.11.1 in my instance), but you may get some milage out of them for different versions.
Firstly, Xcode currently uses Apple's LLVM Compiler as the default C++ compiler. However, this doesn't support some of GCC's extensions, such as support for non-POD variable length arrays.
To get around this, I installed and compile with GCC: if you haven't already, install Homebrew, and then install the latest GCC compiler with:
$ brew install gcc
At the time of writing, this will install GCC v5.2.0.
That should fix your initial problem, but you will instantly hit others!
The next issue is that the included libqc.a will need recompiling for x86_64. So you will need to modify the file <base_dir>/qc/Makefile with the following changes:
...
# Add:
CXX = /usr/local/Cellar/gcc/5.2.0/bin/g++-5
CXXFLAGS = $(ARCHOPT) -c -pedantic -Wall $(DEBUG) $(PRGOPT)
...
Then rebuild libqc.a:
$ cd qc; make clean; make
If all goes well, you should have a shiny new libqc.a.
Finally, modify the main Makefile <base_dir>/Makefile with the following changes:
...
# Comment out:
#PLOPT = -DQCL_PLOT
#PLLIB = -L/usr/X11/lib -lplotter
...
# Comment out:
#RLOPT = -DQCL_USE_READLINE
#RLLIB = -lreadline
#RLLIB = -lreadline -lncurses
...
# Comment out:
#CXX = g++
#CPP = $(CC) -E
#CXXFLAGS = -c $(ARCHOPT) $(DEBUG) $(PLOPT) $(RLOPT) $(IRQOPT) $(ENCOPT) -I$(QCDIR) -DDEF_INCLUDE_PATH="\"$(QCLDIR)\""
#LDFLAGS = $(ARCHOPT) -L$(QCDIR) $(DEBUG) $(PLLIB) -lm -lfl -lqc $(RLLIB)
# Add:
CXX = /usr/local/Cellar/gcc/5.2.0/bin/g++-5
CPP = $(CC) -E
CXXFLAGS = -c $(ARCHOPT) $(DEBUG) $(PLOPT) $(RLOPT) $(IRQOPT) $(ENCOPT) -I$(QCDIR) -DDEF_INCLUDE_PATH="\"$(QCLDIR)\""
LDFLAGS = $(ARCHOPT) -L$(QCDIR) $(DEBUG) $(PLLIB) -lm -ll -lqc $(RLLIB) -lc++
...
This should now allow you to build the main application as per the instructions:
$ make clean; make; make install
Hadoop n00b here, just started playing around with Hadoop Pipes. I'm getting linker errors while compiling a simple WordCount example using hadoop-0.20.203 (current most recent version) that did not appear for the same code in hadoop-0.20.2
Linker errors of the form: undefined reference to `EVP_sha1' in HadoopPipes.cc.
EVP_sha1 (and all of the undefined references I get) are part of the openssl library which HadoopPipes.cc from hadoop-0.20.203 uses, but hadoop-0.20.2 does not.
I've tried adjusting my makefile to link to the ssl libraries, but I'm still out of luck. Any ideas would be greatly appreciated. Thanks!
PS, here is my current makefile:
CC = g++
HADOOP_INSTALL = /usr/local/hadoop-0.20.203.0
SSL_INSTALL = /usr/local/ssl
PLATFORM = Linux-amd64-64
CPPFLAGS = -m64 -I$(HADOOP_INSTALL)/c++/$(PLATFORM)/include -I$(SSL_INSTALL)/include
WordCount: WordCount.cc
$(CC) $(CPPFLAGS) $< -Wall -Wextra -L$(SSL_INSTALL)/lib -lssl -lcrypto -L$(HADOOP_INSTALL)/c++/$(PLATFORM)/lib -lhadooppipes -lhadooputils -lpthread -g -O2 -o $#
The actual program I'm using can be found at http://cs.smith.edu/dftwiki/index.php/Hadoop_Tutorial_2.2_--_Running_C%2B%2B_Programs_on_Hadoop
Had same problem here: answer is to add -lcrypto to the compile command line:
http://grokbase.com/p/hadoop.apache.org/common-user/2011/06/re-linker-errors-with-hadoop-pipes/09zqdt5grdudu7no7q6k3gfcynpy
Here is a patch to fix the build process:
diff --git src/examples/pipes/Makefile.in src/examples/pipes/Makefile.in
index 17efa2a..1d8af8e 100644
--- src/examples/pipes/Makefile.in
+++ src/examples/pipes/Makefile.in
## -233,7 +233,7 ## AM_CXXFLAGS = -Wall -I$(HADOOP_UTILS_PREFIX)/include \
-I$(HADOOP_PIPES_PREFIX)/include
LDADD = -L$(HADOOP_UTILS_PREFIX)/lib -L$(HADOOP_PIPES_PREFIX)/lib \
- -lhadooppipes -lhadooputils
+ -lhadooppipes -lhadooputils -lcrypto
# Define the sources for each program
You just need to make some changes to your Makefile. The libraries that natively accompany hadoop seem not to do it. You'll need to "re-make" them and change your linked path.
A comprehensive answer to this can be found at http://goo.gl/y5iGZF.
I'm trying to use the sprintf() function. Therefore I have to include the stdio.h in my C project. If I compile the project without including the stdio.h in my makefile, the compiler generates the error that sprintf() is a unknown function. Including the stdio.h to the makefile generates the error that there is "no rule to make target."
The makefile template gives the options as follows:
NAME = test
CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld -v
AR = arm-none-eabi-ar
AS = arm-none-eabi-as
CP = arm-none-eabi-objcopy
OD = arm-none-eabi-objdump
CFLAGS = -I./ -c -fno-common -O0 -g -mcpu=cortex-m3 -mthumb
AFLAGS = -ahls -mapcs-32 -o crt.o
ASFLAGS = -Wa,-gstabs
LFLAGS = -Tlinkerscript_rom.cmd -nostartfiles
CPFLAGS = -Obinary
ODFLAGS = -S
I hope that you can help me out, because I have no desire to rewrite every standard function.
Sven
Makefiles don't read include files. The C preprocessor reads include files, before the resulting file is compiled by the compiler. You should include the header in your C file. Just add:
#include <stdio.h>
Somewhere close to the top, before any function definitions etc.
This will show a declaration of the function to the compiler, which will remove the warning.
Just include stdio.h at the top of your c file
#include <stdio.h>
The only reason to put a .h file in your makefile is so that the files dependent upon your header will be recompiled if anything in the header is changed. Needless to say, this is most commonly with header files you have written.
If there is an error after including stdio.h, you have a broken tool chain. If you update your question to indicate your platform, we may be able to help you fix it :)
Hello I would like to ask you, If someone knows how can I add a directory for the header files in the Makefile to avoid the error *.h not found, I have tried this option but does not work:
INC_PATH := -I /directory/to/add
At least for GNU make, try the implicit variable CFLAGS, as in:
CFLAGS=-I/directory/to/add
Although the goal is ultimately to affect the value of CFLAGS (as suggested by #unwind), it is often not a good idea to simply set the value of CFLAGS as it is often built out of many pieces. You have to understand the structure of the makefile, and the set of macros used.
[Added:
Eduardo asked: Can you post macros to do the same?
Yes, but whether they are helpful depends on how your makefiles are structured. Here's a moderately complex example from one of my makefiles.
CC = gcc -g
XFLAGS = -Wall -Wshadow -Wstrict-prototypes -Wmissing-prototypes \
-DDEBUG -Wredundant-decls
#CC = cc -g
#XFLAGS =
UFLAGS = # Always overrideable on the command line
DEPEND.mk = sqlcmd-depend.mk
INSTALL.mk = sqlcmd-install.mk
ESQLC_VERSION = `esqlcver`
OFLAGS = # -DDEBUG_MALLOC -g
OFLAGS = -g -DDEBUG -O4
PFLAGS = -DHAVE_CONFIG_H
OFILES.o = # rfnmanip.o # malloc.o # strdup.o # memmove.o
VERSION = -DESQLC_VERSION=${ESQLC_VERSION}
#INC1 = <defined in sqlcmd-depend.mk>
#INC2 = <defined in sqlcmd-depend.mk>
INC3 = /usr/gnu/include
INC4 = ${INFORMIXDIR}/incl/esql
INC5 = . #${INFORMIXDIR}/incl
INCDIRS = -I${INC3} -I${INC1} -I${INC2} -I${INC4} -I${INC5}
LIBSQLCMD = libsqlcmd.a
STRIP = #-s
LIBC = #-lc_s
LIBMALLOC = #-lefence
LIBRDLN = -lreadline
LIBCURSES = -lcurses
LIBPOSIX4 = -lposix4
LIBG = #-lg
LIBDIR1 = ${HOME}/lib
LIBDIR2 = /usr/gnu/lib
LIBJL1 = ${LIBDIR1}/libjl.a
LIBJL2 = ${LIBDIR1}/libjlss-${ESQLC_VERSION}.a
LIBTOOLS = ${LIBJL2} ${LIBJL1}
LDFLAGS = ${LIBSQLCMD} ${LIBTOOLS} -L${LIBDIR2} ${LIBG} ${LIBMALLOC} \
${LIBPOSIX4} ${LIBC} ${STRIP}
CFLAGS = ${VERSION} ${INCDIRS} ${OFLAGS} ${XFLAGS} ${PFLAGS} ${UFLAGS}
This a makefile for a program of mine called sqlcmd (a name chosen a decade and more before Microsoft created a command of the same name). I assume that the make program has a rule for compiling C code to object like:
${CC} ${CFLAGS} -c $*.c
and that the rule for linking a program from a set of object files listed in the macro OBJECTS looks like:
${CC} ${CFLAGS} -o $# ${OBJECTS} ${LDFLAGS}
As you can see, there are separately settable macros for the ESQLC_VERSION (the version of Informix ESQL/C in use, derived by default by runing a script esqlcver), then the include directories via INC1 to INC5 and INCFLAGS (there can be quite a lot of these, depending on platform), and optimizer flags (OFLAGS), extra flags (CFLAGS), user-defined flags (UFLAGS - an idiom I use in most of my makefiles; it allows the user to set UFLAGS on the make command line and add an extra flag to the build), and a bunch of library-related macros. This is what it takes for my development makefile to be tunable with minimal fuss to my development platform, which can be Linux, Solaris or MacOS X. For consumers of the program, there is a configure script generated by autoconf, so they don't have to worry about getting those bits right. However, that has a strong genetic resemblance to this code, including the UFLAGS option.
Note that many systems for makefile building have a mechanism for setting CFLAGS faintly similar to this - and simply assigning to CFLAGS undoes the good work done by the system. But you have to understand your makefile to be able to modify it sanely.
]