I have a system in which I've been compiling programs with C++11 using automake and everything has been working.
However, when a different user take the same exact Makefile they get the aforementioned error.
Now, if they type in g++ --std=gnu++11 program.cpp then there are no complaints.
I've narrowed it down to a line that is causing the issue; however, I don't know how to fix it.
depbase=`echo no_endl.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -I../.. -g --std=gnu++11 -g -O2 -MT no_endl.o -MD -MP -MF $depbase.Tpo -c -o no_endl.o no_endl.cpp &&\
mv -f $depbase.Tpo $depbase.Po
The problem is with depbase; however, I don't know what is going on with it or why it is there.
Below is the Automake file that I used to generate the Makefile:
bin_PROGRAMS = no_endl
AM_CXXFLAGS = -g --std=gnu++11
no_endl_SOURCES = no_endl.cpp
The only difference between my g++ and their g++ is I have an alias so g++ turns into g++ -g.
Helpful information
g++ --version
g++ (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If there is any other information that I need to provide, then let me know.
Related Question
I solved the problem.
The problem was the $PATH variables for me and other users.
Now, other users have an alias for g++ to the newer version, but their $PATH omits the actual location.
Make works based on their $PATH variable, so to fix it, I just had to make sure their path had the same location as mine.
You probably need the following additional m4 macro file that handles corner cases of substituted C++11 compilers.
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html#ax_cxx_compile_stdcxx_11
Related
My main development platform is Gentoo on Linux. However, recently I tried to build my program on the fresh VM install on Debian.
My program contains of main binary and couple of dll/so/dylib libraries. One of the libraries depends on the presence of unixODBC/iODBC.
I was told by unixODBC maintainers to use odbc_config script to identify the build parameters.
When I build on Gentoo - everything works fine. There is no problems.
However, when I build on Debian - the build fails because apparently Debian does not produce odbc_config script and instead in this case rely on pkg-config.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation (lets call it libodbc_lib project).
Could someone please help me with this?
EDIT:
Is this correct to be put in configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
If it is - how do I use ODBC_FLAGS/ODBC_LIBS in my subproject?
EDIT2:
Based on this answer I used the following code:
In the main configure.ac:
AC_CHECK_PROG(ODBC,odbc_config,yes)
if test x"${ODBC}" == x"yes" ; then
ODBC_CFLAGS = `odbc_config --cflags`
ODBC_LIBS = `odbc_config --libs` -lodbcinst
else
ODBC_CFLAGS = `pkg-config odbc --cflags`
ODBC_LIBS = `pkg-config odbc --libs` -lodbcinst
fi
AC_SUBST(ODBC_CFLAGS)
AC_SUBST(ODBC_LIBS)
In the libodbc_lib/Makefile.am:
libodbc_lib_la_CXXFLAGS = -I../../dbinterface \
-DUNICODE \
-DUNIXODBC \
-I#ODBC_CFLAGS#
libodbc_lib_la_LDFLAGS = -L../dbinterface \
-ldbinterface \
#ODBC_LIB#
I regenerated configure, run it successfully and then tried running make.
I got following error:
CXXLD libodbc_lib.la
/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find #ODBC_LIB#: No such file or directory
What I did wrong?
EDIT3:
After fixing the missing S, I got following compile commands:
make[2]: Entering directory '/home/igor/dbhandler/Debug/libodbc'
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c -o libodbc_lib_la-database_odbc.lo `test -f 'database_odbc.cpp' || echo '/home/igor/dbhandler/libodbc/'`database_odbc.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -fPIC -DPIC -o .libs/libodbc_lib_la-database_odbc.o
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/home/igor/dbhandler/libodbc -I.. -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -MT libodbc_lib_la-database_odbc.lo -MD -MP -MF .deps/libodbc_lib_la-database_odbc.Tpo -c /home/igor/dbhandler/libodbc/database_odbc.cpp -o libodbc_lib_la-database_odbc.o >/dev/null 2>&1
mv -f .deps/libodbc_lib_la-database_odbc.Tpo .deps/libodbc_lib_la-database_odbc.Plo
/bin/sh ../libtool --tag=CXX --mode=link g++ -I../../dbinterface -DUNICODE -DUNIXODBC -I#IODBC_CFLAGS# -g -O0 -L../dbinterface -ldbinterface -o libodbc_lib.la -rpath /usr/local/lib libodbc_lib_la-database_odbc.lo
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtbeginS.o .libs/libodbc_lib_la-database_odbc.o -L../dbinterface -ldbinterface -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/../../../../lib64/crtn.o -g -O0 -Wl,-soname -Wl,libodbc_lib.so.0 -o .libs/libodbc_lib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so.0" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so.0")
libtool: link: (cd ".libs" && rm -f "libodbc_lib.so" && ln -s "libodbc_lib.so.0.0.0" "libodbc_lib.so")
libtool: link: ar cru .libs/libodbc_lib.a libodbc_lib_la-database_odbc.o
libtool: link: ranlib .libs/libodbc_lib.a
libtool: link: ( cd ".libs" && rm -f "libodbc_lib.la" && ln -s "../libodbc_lib.la" "libodbc_lib.la" )
make[2]: Leaving directory '/home/igor/dbhandler/Debug/libodbc'
I still the variable name there and not their values.
Is it normal?
As UnixODBC upstream does ship and install *.pc files, I would expect that file to be both present and correct and therefore I would ignore any *-config scripts. The pkg-config system is quite well thought out and works even for quite weird cross compilation environments. The *.pc mechanism works well on Linux, on FreeBSD, on OSX, cross-compiling for Windows on Linux, to name a few.
A well-written _config program written in portable shell could do the same by basically reproducing much of the pkg-config logic in portable shell for each and every _config script, hopefully correctly.
However, odbc_config is not a portable shell script. It is a binary executable, i.e. it will regularly break for cross-compiling, as the system you build on will usually not be able to run programs like odbc_config which are built to run on the system you are building for.
And even if the flags from the *.pc files were unsuitable for a very unusual build environment: Using PKG_CHECK_MODULES defines appropriate _CFLAGS and _LIBS variables for the configure script, so even in a very unusual build environments one can always override whatever the *.pc file might contain by calling configure like
../configure ODBC_CFLAGS='-I/weird/stuff -DWEIRD_STRING="moo"' ODBC_LIBS='-L/very/weird/libxyz -lodbc'
So... using odbc_config has no advantages, upstream already provides a odbc.pc file so it is always present, so why not just always use odbc.pc?
So, in configure.ac (if builds without odbc.pc present should fail, otherwise you will have to do some AC_DEFINE and/or AM_CONDITIONAL to conditionally build with or without ODBC support) do
m4_pattern_forbid([PKG_CHECK_MODULES])dnl
PKG_CHECK_MODULES([ODBC], [odbc])
and in any subdirectory (what you call "subproject") Makefile.am or Makefile-files where you need to link somehting against libodbc, put, depending on whether you are building an executable
bin_PROGRAMS += foobar
[…]
foobar_CPPFLAGS += $(ODBC_CFLAGS)
foobar_LDADD += $(ODBC_LIBS)
or a (libtool) library
lib_LTLIBRARIES += libfoo.la
[…]
libfoo_la_CPPFLAGS += $(ODBC_CFLAGS)
libfoo_la_LIBADD += $(ODBC_LIBS)
That should work for all native and cross-compile builds in properly set up build environments, and people can still override odbc_CFLAGS and odbc_LIBS in case of problems.
Of course, you can always AC_CHECK_PROG or AC_PATH_PROG or AC_CHECK_TOOL or AC_PATH_TOOL together with an AC_ARG_VAR for the odbc_config program and then define and AC_SUBST an _CFLAGS and _LIBS variable set to the output of $ODBC_CONFIG --cflags and $ODBC_CONFIG --libs, respectively, and then then use the _CFLAGS and _LIBS vars in Makefile.am/Makefile-files as above.
However, that is a lot of code to write, and with a lot of special cases to consider, and if you have to ask about how to do this you will probably get a lot more wrong than if you just just use PKG_CHECK_MODULES.
You can always add something later if the PKG_CHECK_MODULES route actually does not work for a use case and which cannot be fixed within the pkg-config framework. Until that time (if it ever happens), I would recommend to just use the simple PKG_CHECK_MODULES method and probably be done.
So, I need to add a test in configure.ac to check for odbc_config script presence and pass it along to one of the so files generation
Autoconf has AC_PATH_PROG() for checking for a program in the executable search path. You would of course use AC_SUBST() to define one or more output variables by which to convey the results to the generated makefiles.
But no, coming back around to my comment on the answer to one of your previous questions, what you ought to do is not have configure forward information about the executable, but rather for it to determine the needed flags itself and forward them, via one or more output variables. If you continue to use odbc_config, at least conditionally, then that means having configure run it and capture the output. You should not inject shell command substitutions into your compilation commands.
And if you substitute a different mechanism, whether conditionally or exclusively, then similarly for that. (That's what your other answer describes with respect to pkg-config.)
I have a simple project with a simple configure.ac script:
AC_INIT(...)
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_PROG_CC
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES(...)
AC_OUTPUT
using GNU Autoconf version 2.69 (OpenSUSE Linux with gcc 9.2.1), but gcc is being called with no warning flags:
gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT aprog.o -MD -MP -MF .deps/aprog.Tpo -c -o aprog.o aprog.c
mv ...
gcc -g -O2 -o aprog aprog.o -lgmp
In particular, I found -Wformat not working. Shouldn't -Wall include -Wformat? And shouldn't all warnings appear on the make line? If I run gcc line directly with -Wformat the warning shows in compile but it doesn't when I run autoconf, configure and make.
What I'm doing wrong?
The -Wall flag in the AM_INIT_AUTOMAKE(...) invocation refers to warnings from automake and related tools like aclocal, not to compiler warnings. You will see these warnings when you are running autoreconf.
Note that while you can also add -Werror to AM_INIT_AUTOMAKE(...) to make your autoreconf run fail on warnings, many common macros (like those shipped with gettext or libtool) will still use deprecated macros which generates a warning, so -Werror means you cannot use this standard set of tools, so -Werror is not very useful in many cases.
If you want to add compiler options, there are a third party macros (e.g. AX_CHECK_COMPILE_FLAG) which test whether the compiler recognizes a given compile option and you can then add them to some variable and use that in places. That is a different stackoverflow question, though.
In my build script, I want to conditionally add -fstack-protector-strong to my CFLAGS if the gcc supports it (my project builds using multiple versions of gcc).
I want my build script (written in bash) to parse the output of gcc --version and automatically add this flag if the gcc supports it.
Which version of gcc is the earliest to include the -fstack-protector-strong flag?
I want my build script (written in bash) to parse the output of gcc --version and automatically add this flag if the gcc supports it.
Instead of doing that, just call gcc -fstack-protector-strong with a valid source file and see if it compiles. Such method works universally for any compile option, which will save you time for searching which version has which options. You may take inspiration from CMake check_c_compile_flag function.
Taking inspiration from #KamilCuk's answer but bashifying it:
add_supported_cc_flag() {
CC=$1
CFLAG_TO_CHECK=$2
C_FILE=/tmp/test.$$.c
O_FILE=${C_FILE/.c/.o}
rm -f ${C_FILE}
cat > ${C_FILE} <<EOF
int main() { return 0; }
EOF
if $CC ${CFLAG_TO_CHECK} -c ${C_FILE} -o ${O_FILE} >/dev/null 2>&1
then
echo ${CFLAG_TO_CHECK}
fi
rm -f ${C_FILE} ${O_FILE}
}
CFLAGS="${CFLAGS} $(add_supported_cc_flag gcc -fstack-protector-strong)"
It appears that -fstack-protector-strong was first available in gcc 4.9.0.
The option doesn't show up in https://gcc.gnu.org/onlinedocs/gcc-4.8.5/gcc/Optimize-Options.html (4.8.5 was the last 4.8.x gcc version), but the option does show up in https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Optimize-Options.html.
Note that -fstack-protector-all and -fstack-protector are available prior to gcc 4.9.0.
I've got a problem with the way I am shelling out. I'm working with Bash, but its on Debian Sid (Unstable) in a ARM64 Chroot. (I'm doing this because its our Debian package maintainer. Otherwise, I run away from the unstable, bleeding edge stuff)...
# echo $0
/bin/bash
It appears one of my shell commands is creating an -o2 rather than an -O2. I suspect memory is being trashed while shelling out, and the -o2 is just a symptom.
# make cryptlib.o
g++ -DNDEBUG -g3 -o2 -pipe -c cryptlib.cpp
Here's the same command under Remake:
# remake -X -f GNUmakefile cryptlib.o
GNU Make 3.82+dbg0.9
Built for aarch64-unknown-linux-gnu
Copyright (C) 2010 Free Software Foundation, Inc.
...
Updating goal targets....
File `cryptlib.o' does not exist.
Must remake target `cryptlib.o'.
Invoking recipe from GNUmakefile:449 to update target `cryptlib.o'.
##>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
g++ -DNDEBUG -g3 -o2 -pipe -c cryptlib.cpp
##<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
++ (/cryptopp-git/GNUmakefile:448)
cryptlib.o
remake<0>
As can be seen, the stuff I am interested in has already passed. Line 449 is very uninteresting. Its just a standard recipe that uses CXX, CXXFLAGS and $<.
Unfortunately, I don't really see what I should be doing to debug this issue. According to 1.1.6 Debugging Shell Commands, there's a step, but it does not really tell me how to use it. When I attempt to add it to the command:
remake -X step -f GNUmakefile cryptlib.o
It results in No rule to make target 'step'.
How do I debug this makefile with Remake? Or even without it?
The recipe's in your makefile aren't involved with setting that variable's value.
That's is a make variable. It is set at make-parse time by make itself (and the make-level contents of your makefile).
I don't see anything in the linked GNUMakefile that says either -o2 or -g3 both of which are in the make-run compilation command.
That makefile does include a GNUMakefile.deps file if it exists. I suppose that might have the erroneous value in it. Do you have a GNUMakefile.deps file?
Does grep find -g3 or -o2 anywhere in your source directory? (In case there's some other included makefile?)
The last place that make might be getting this value from is the process environment (because CXXFLAGS is defined with the ?= operator).
Do you have CXXFLAGS defined incorrectly in your environment?
I think I have added the -g option in the makefile. The makefile is like this:
C=edgelist.c geometry.c heap.c main.c memory.c output.c voronoi.c
O=edgelist.o geometry.o heap.o main.o memory.o output.o voronoi.o
tt: voronoi t
./voronoi -t <t >tt
voronoi: $O
cc -g -o voronoi $O -lm
$O:vdefs.h
voronoi.tar : $C vdefs.h Makefile Doc t
tar -cf voronoi.tar $C vdefs.h Makefile Doc t
mailable: $C vdefs.h Makefile t
bundle $C vdefs.h Makefile t > mailable
When gdb runs the program:
jack#ubuntu:~/下载/voronoi$ gdb ./voronoi
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/jack/下载/voronoi/voronoi...(**no debugging symbols found**)...done.
(gdb)
What's the problem?
Each of the object files has to be created with -g, and the executable has to be linked with -g. At the moment, you are linking with -g but not compiling with -g.
Given the structure of your makefile, the simplest fix is probably:
$O: vdefs.h
gcc -g -c $*.c
However, ideally, you should set things up so that you use CC and CFLAGS. For example:
CFLAGS = -g -Wall -Wextra -Werror
CC = gcc # May be unnecessary
LDLIBS = -lm
Then you don't need the gcc line after $O: vdefs.h. Your linking line should become:
${CC} -o $# ${CFLAGS} $O ${LDFLAGS} ${LDLIBS}
or thereabouts.