How to tell Libtool to use C++ and not C? - c++

I am working on an Autools front-end for a C++ library. It looks like Libtool is adding C source files to the project and its causing a fair amount of trouble on some platforms. We think its causing unexplained crashes like Message “During startup program terminated with signal SIGKILL” from GDB.
The C source files cause trouble for several reasons. First, we only query CXXFLAGS and set AM_CXXFLAGS; and we don't do anything with CFLAGS or AM_CFLAGS. Second, C files need additional options in a C++ project, like -frtti and -fexceptions under GCC and options like -qrtti under IBM XL C/C++ compiler. Its not clear to me if libtool is adding the necessary options. Third, the C source files added by Libtool need additional Posix options on platforms that use Newlib, like Cygwin and MSYS. Our source files don't need the options.
I'd like to force Libtool to use C++ instead of C but I have not been able to locate an option or method to do so. I think the easiest path would be for Libtool to use lt-<some file>.cpp and CXXFLAGS rather than lt-<some file>.c and CFLAGS but I can't figure out how to do it.
How do we tell Libtool to use C++ and not C?
A related problem is How to disable C compiler in C++ Autotools project, but it only ask to use the C++ compiler for feature testing.

You could add the C compiler options you mention to the CFLAGS env var before compilation. Do you see any reasons why this would not work?

Related

C++ Canonical Project Structure, can't find headers

I'm fairly new to C++ and writing makefiles. I'm trying to compile a C++ project with the "canonical" structure described here with a makefile. I'm running into a problem where the compilation is failing because it can't find the headers due to using <brackets> instead of "quotes" when including the headers.
How do I tell the compiler where to find the headers in the project?
Usually, you would use the -I option, followed by a relative or absolute path to the directory where the headers are.
For example:
gcc -c src/foo.c -o obj/foo.o -I src
(However, compiler options are not part of the C++ standard, so it depends on what compiler you are using, and you did not say.)

Is it possible to add debug symbols to an existing C++ .so (shared library)?

I have a work project that relies on a very large, inherited C++ shared library that was released without debug symbols and we only have the .h includes. Often, there is a need to see how those functions act on values passed in but debugging in gdb skips over those functions. Is it possible for me to build the sources myself to ensure the debug symbols are there? I have tried adding the -g flag to the CXXFLAGS section in my Makefile but that didn't seem to do it. Any help or insight would be greatly appreciated.
Is it possible for me to build the sources myself to ensure the debug symbols are there?
If you have the sources, then yes.
I have tried adding the -g flag to the CXXFLAGS section in my Makefile but that didn't seem to do it.
Assuming that by "my Makefile" you mean the Makefile which builds the library, and not the Makefile which builds your application, adding -g should be all that's required.
"Didn't seem to do it" can mean any number of things.
Did you add -g to the right place?
Did the build succeed?
Did you arrange for the application to use the newly-built library?
There is not enough info in your question to guess.

Getting the C++ compilers in Code::Blocks and Visual Studio to adhere to C++(11) standard?

I use two C++ compilers / IDEs. (1) g++ in Code::Blocks and (2) Visual C++ in Visual Studio.
I have some question on how to set up the compiler in the way I want it to be.
Code::Blocks: I want to make G++ follow standard C++. For example:
int x;
cin >> x;
int arr[x];
...wouldn't work in standard C++.
In standard C++, one has to use dynamic allocation. For example, the Visual C++ compiler would reject this code. However, this code would work in Code::Blocks.
How do I make g++ reject this code?
Also, how do I tell g++ and Visual C++ 2013 to follow and only follow C++11 standard? It seems to me the default one is still C++98/03.
Compiler options for standard-conformance.
With g++ you want, at minimum,
-std=c++11 for the C++11 standard.
-pedantic to warn about use of language extensions.
-Wall -Wextra to up the warning level to reasonable.
With Visual C++ you want, at minimum,
/nologo to turn off a verbose version and copyright message,
/EHsc to turn on exception support,
/GR to turn on RTTI support, Run Time Type Information such as dynamic_cast,
/W4 to up the warning level to reasonable.
With Visual C++ there is no special option to indicate the C++ standard version.
How to preset options for command line use.
MinGW g++ generally (one exception is the Nuwen distribution) defaults to producing executables that rely on DLLs that reside in the mingw\bin directory, which means that you generally need that in your PATH environment variable.
This means that it's not such a good idea to add options via a batch file or shortcut or command intepreter macro. Instead use option -dumpspecs and redirection to create a specs file (with that name) in the directory specified by this Windows command:
g++ --print-search-dirs | find "install:"
Read up on how to edit that file, then fix it. ;-)
You might want to set the CPATH environment variable to your general include directory.
With Visual C++:
Compilers options can be preset in the CL environment variable.
Include paths in the INCLUDE variable.
Library paths in the LIB variable.
Linker options can be preset in the LINK variable.
For the linker options you may want to have /entry:mainCRTStartup to support ordinary standard main startup function also when producing a GUI subsystem executable. However this conflicts a little with MFC. It's been many years since I did anything MFC so if you want details or solution please post a separate question which others can answer.
How to set options in each IDE (Code::Blocks, Visual Studio).
This is as simple as reading each IDE's documentation. ;-)
Note that options can be set both globally and per project.

How to set -std=c++0x in compiler option in eclipse makefile project?

I need to set the compiler options in my makefile project in eclipse.
I followed this instruction:
http://www.eclipse.org/forums/index.php/mv/msg/282618/787571/
where the last part states:
Obviously make sure your rule includes "-std=c++0x" as a compiler option.
But there are no "tool-settings" in the project properties of my makefile project.
Is there another way to set the compiler options for a makefile project?
Thanks.
If it's a makefile project, then the makefile specifies how to build it, not the Eclipse settings.
Exactly how to specify the compiler options depends on how the makefile is written, but typically they are in a variable called CXXFLAGS, since that's what the default C++ build rule uses.
Unless you need to support outdated compilers, I suggest specifying c++11 rather than c++0x.

Conditionally disable warnings with qmake/gcc?

I am involved with a software project written in Qt and built with qmake and gcc on Linux. We have to link to a third-party library that is of fairly low quality and spews tons of warnings. I would like to use -W -Wall on our source code, but pass -w to the nasty third-party library to keep the console free of noise and clutter so we can focus on our code quality.
In qmake, is there a way to conditionally add CFLAGS/CXXFLAGS to certain files and libraries?
Jonathan, I think the problem is where your source files are including header files from 3rd party libraries, and you want to switch off the warnings for the latter.
Kevin, i think you can use pragmas to control warnings : gcc diagnostic pragmas
You could add these before and after any #includes for 3rd party libs.
What if you include your library using -isystem.
In the project file e.g.:
QMAKE_CXXFLAGS += -isystem /usr/local/boost_1_44_0
Normally, you'd build the third-party library in a separate directory from your own code, so you would have a different makefile for it, so you could put a different set of flags for that compilation.
If you've mixed the third-party library code with your own code, you have set yourself up for a maintenance nightmare.
Kevin,
qmake CONFIG+=debug QMAKE_CXXFLAGS_WARN_ON=-w QMAKE_CFLAGS_WARN_ON=-w
should do
(use CONFIG+=release if you wish...)
As Martin wrote adding the include directory via
QMAKE_CXXFLAGS += -isystem ...
suppresses warnings just in the respective headers. No need to disable warnings for any source files of your project (or even project-wide) or mess with #pragmas or wrappers files.
Note that if you're using QtCreator you'll still (i.e. additionally) want add the directory to INCLUDEPATH so the indexer picks up the headers.