How to test a C++ library usability in configure.in? - c++

I'm working on a C++ project on GNU/Linux and I'm looking for a way to test the existence and usability of IBM Informix's library with the Autotools - namely, editing a configure.in. I don't have experience with Autotools, so basically I'm picking up from the project's configure.in et al. scripts and copying&changing where I feel needs to be changed. IOW, I've been adapting from the existing text in configure.in.
So far I've been using successfully the AC_CHECK_LIB in configure.in to test whether a certain library both exists and is usable. But this only seems to work with libraries with functions, not e.g. classes. Namely, this fails when testing Informix's libifc++.so library:
AC_CHECK_LIB(ifc++, ITString,
INFORMIX_LIB="-L$INFORMIX_LIB_LOCATION/c++ -lifc++ -L$INFORMIX_LIB_LOCATION -L$INFORMIX_LIB_LOCATION/dmi -L$INFORMIX_LIB_LOCATION/esql -lifdmi -lifsql -lifasf -lifgen -lifos -lifgls -lifglx $INFORMIX_LIB_LOCATION/esql/checkapi.o -lm -ldl -lcrypt -lnsl",
echo "* WARNING: libifc++.so not found!"
INFORMIX_INC=""
INFORMIX_LIB=""
)
I've also tried using other combinations, like ITString::ITString, etc.
I haven't found a "pure" function in Informix's API (i.e., one that isn't contexted in a C++ class). So I'm hoping that either there's a way to use AC_CHECK_LIB in this context, or there's another autoconf/configure.in "command" for this specific use.
Thanks in advance for your feedback.

You've discovered a shortcoming of autotools, but one that can't really be helped. Autotools checks for symbol names in the library binary, and unlike C where symbol names of functions are identical to the function names, C++ "mangles" function's symbol names to accomplish things like function overloading. What's worse is that C++ doesn't really even have a "standard" mangling convention, so different C++ compilers may produce different symbol names for the same function. Thus, autotools can't check for C++ symbol names in a reliable manner.
Does the library you are trying to use have any functions that are declared with extern "C"? This causes the C++ compiler to generate standardized C-style symbol names, and autotools will be able to find them.
I ran into this issue trying to detect gtest and gmock (the Google unit testing and object mocking frameworks) with Autotools, and here's what I came up with:
# gtest has a main function in the gtest_main library with C linkage, we can test for that.
AC_CHECK_LIB([gtest_main], [main], [HAVE_GTEST=1] [TEST_LIBS="$TEST_LIBS -lgtest_main"],
AC_MSG_WARN([libgtest (Google C++ Unit Testing Framework) is not installed. Will not be able to make check.]))
# gmock has no functions with C linkage, so this is a roundabout way of testing for it. We create a small test
# program that tries to instantiate one of gmock's objects, and try to link it with -lgmock and see if it works.
if test "$HAVE_GTEST"
then
saved_ldflags="${LDFLAGS}"
LDFLAGS="${LDFLAGS} -lgtest -lgmock"
AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <gmock/gmock.h>], [testing::Cardinality dummy])],
[TEST_LIBS="$TEST_LIBS -lgmock"] [HAVE_GMOCK=1],
[AC_MSG_WARN([libgmock (Google C++ Object Mocking Framework) is not installed. Will not be able to make check.])])
LDFLAGS="${saved_ldflags}"
fi

There might be a cleaner way of achieving this, but I think your problem is that C++ methods get "mangled" to allow additional information about the method (argument & return types etc) to be encoded. For example; the method int A::foo(void) will get mangled to something like __ZN1A3fooEv.
So you need to find the mangled name of a method in the library. You can do this by using the nm command on Unix-like OSs:
$ nm libifc++.so | grep ITString
It's worth mentioning that the exact mangling format varies across different compilers; and so by embedding a certain compiler's mangled symbol in your configure.in it may not work on other platforms - YMMV.
Note: you can use the c++filt utility to demangle a name back to it's human-readable form; so for the example I gave previously:
$ c++filt __ZN1A3fooEv
A::foo()
See Name Mangling in C++ on Wikipedia for more information.

If the library you are checking for supports pkg-config, this becomes very easy. Here is all I added to my configure.in to check for and enable gtest and gmock:
dnl ************************************
dnl Check for googletest and googlemock
dnl ************************************
PKG_CHECK_MODULES(gtestmock, libgtest >= 0.4.0, libgmock >= 0.4.0)
AC_SUBST(gtestmock_LIBS)
AC_SUBST(gtestmock_CFLAGS)
And then in my Makefile.am somewhere:
sometarget_CXXFLAGS = $(gtestmock_CFLAGS) $(AM_CXXFLAGS)
sometarget_LDADD = $(gtestmock_LIBS)
Pretty trivial, eh?

AC_LANG_CPLUSPLUS
AC_CHECK_LIB(Sockets, main)
Caveat: http://lists.gnu.org/archive/html/autoconf/2006-09/msg00019.html

Related

Barebones C++ without standard library?

Compilers such as GCC and Clang allow to compile C++ programs without the C++ standard library, e.g. using the -nostdlib command line flag. It seems that such often fail to link thou, for example:
void f() noexcept { throw 42; }
int main() { f(); }
Usually fails to link due to undefined symbols like __cxa_allocate_exception, typeinfo for int, __cxa_throw, __gxx_personality_v0, __clang_call_terminate, __cxa_begin_catch, std::terminate() etc.
Even a simple
int main() {}
Fails to link with
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400120
and is killed by the OS upon execution. Using -c the compiler still runs the linker which blatantly fails with:
ld: error in mytest(.eh_frame); no .eh_frame_hdr table will be created.
Is it a realistic goal to program and compile C++ applications or libraries without using and linking to the standard library? How can I compile my code using GCC or Clang on Linux? What core language features would one be unable to use without the standard library?
You will basically find all of your questions answered at osdev.org, but I'll give a brief summary anyway.
When you give GCC -nostdlib, you are saying "no startup or library files". This includes:
crti.o, crtbegin.o, crtend.o and crtn.o. Generally kernel developers only care about implementing crti.o and crtend.o and let GCC supply crtbegin.o and crtend.o by passing -print-file-name= to the linker. Generally these are just stubs that consist of .init and .fini respectively, leaving room for GCC to shove the contents of crtbegin.o and crtend.o respectively. These files are necessary for calling global constructors/destructors.
You can't avoid linking libgcc (the "low-level runtime library" (-lgcc) because even if you pass -nostdlib GCC will emit calls to its functions whenever you use it, leading to inexplicable linking errors for seemingly no reason. This is the case even when you're implementing/porting a C library.
You don't "need" libstdc++ no, but typically kernel developers want it. Porting a C library then implementing the C++ standard library from scratch is an extremely difficult task.
Since you only want to get rid of the "standard library", but keeping libc (on a Linux system) you're essentially programming C++ with just a C library. Of course, there's nothing wrong with this and you do you, but ultimately I don't see the point unless you plan on developing a kernel.
Required reading:
OSDev's C++ page - If you really care about RTTI/exception support, it's more annoying to implement than it sounds. Typically people just pass -fno-rtti or -fno-exceptions and then worry about it down the line or not at all.
"Standard" is a misnomer. In this context it doesn't mean "the library (set of functions, classes etc) as defined by the C++ standard" but "the usual set of libraries and objects (compiled files in a certain format) gcc links with by default". Some of those are necessary for most or even all programs to function.
If you use this flag, it's your responsibility to provide any missing functionality. There are several ways to do so:
Cherry-pick libraries and objects that your program really needs out of the default set. (Makes little sense as the result will most probably be exactly the same as with the default link flags).
Provide your own implementation of missing functionality.
Explicitly disable, through compiler flags, language features your program isn't using. I know of two such features: exceptions and RTTI. This is needed because the compiler needs to generate exceptions-related code and RTTI info even if these features are not explicitly used in this module.

How to use SWIG for D from C++ on Windows?

I want to use LEAP Motion in D.
Therefore It doesn't have C library and It has only C++ library.
I tried SWIG 2.0.9 below command.
swig -c++ -d -d2 leap.i
This command output Leap.d, Leap_im.d, Leap_wrap.cxx, Leap_wrap.h.
However, I don't know how to use to wrapper in D and I can't find how to use the wrapper.
Link error displays to use it intact.
How use these wrapper in D2?
And can I use without Leap.cpp (source of Leap.dll)?
Update:
Thanks two answers. and sorry for reply late because of busy.
Say first conclusion I could build Leap sample code on Win64 by following the steps below.
Output wrappers by above command.
Create x64 DLL with VC2010 from Leap_wrap.cxx, Leap_wrap.h, and import Leap.lib(x64).
Compile Leap.d and Leap_im.d with dmd -c.
Build LeapTest.d with Leap.obj and Leap_im.obj
all command is below.
swig -c++ -d -d2 leap.i
dmd -c Leap.d Leap_im.d -m64
dmd LeapTest.d Leap.obj Leap_im.obj -m64
execute LeapTest.exe (require x64 Leap.dll and Leap_wrap.dll)
I could run Leap Program.
But program crach onFrame event callback.
I'll try again on x86 and investigate the causes.
Few helpful links (some information may be outdated):
http://klickverbot.at/blog/2010/11/announcing-d-support-in-swig/
http://www.swig.org/Doc2.0/D.html
http://www.swig.org/tutorial.html
I have never used SWIG personally but my guess based on general knowledge about SWIG:
Leap_wrap.cxx is C++ source file that wraps calls to C++ functions from target library in extern(C) calls
Leap_wrap.h is header file with all extern(C) wrappers listed
Leap_im.d is D module based on Leap_wrap.h with same extern(C) function listed
Leap.d is D module that uses Leap_im.d as an implementation and reproduces API similar to original C++ one.
So in your D code you want to import Leap.d module. Than compile Leap_wrap.cxx to an object file with your C++ compiler and provide D object files, Leap_wrap.o and target library at linking stage. That should do the trick.
P.S. Leap.cpp source should not be needed. All stuff links directly from Leap_wrap.cxx to target library binary.
Go to IRC, either FreeNode, or OFTC, channel #D. In order to help you, we have to see what is in those files. My first guess is that you have to compile both D files, and the C++ file into object files, and link them together. I suppose SWIG is going to flatten the C++ API into bunch of C functions, and that is probably what Leap_wrap.cxx does.
If the LEAP API is not complex (ie. just bunch of simple C++ classes), it may be possible to directly interface with it. Read more about it here: http://dlang.org/cpp_interface.html .

How to debug GCC/LD linking process for STL/C++

I'm working on a bare-metal cortex-M3 in C++ for fun and profit. I use the STL library as I needed some containers. I thought that by simply providing my allocator it wouldn't add much code to the final binary, since you get only what you use.
I actually didn't even expect any linking process at all with the STL
(giving my allocator), as I thought it was all template code.
I am compiling with -fno-exception by the way.
Unfortunately, about 600KB or more are added to my binary. I looked up what symbols are included in the final binary with nm and it seemed a joke to me. The list is so long I won't try and past it. Although there are some weak symbols.
I also looked in the .map file generated by the linker and I even found the scanf symbols
.text
0x000158bc 0x30 /CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/usr/lib/libc.a(sscanf.o)
0x000158bc __sscanf
0x000158bc sscanf
0x000158bc _IO_sscanf
And:
$ arm-none-linux-gnueabi-nm binary | grep scanf
000158bc T _IO_sscanf
0003e5f4 T _IO_vfscanf
0003e5f4 T _IO_vfscanf_internal
000164a8 T _IO_vsscanf
00046814 T ___vfscanf
000158bc T __sscanf
00046814 T __vfscanf
000164a8 W __vsscanf
000158bc T sscanf
00046814 W vfscanf
000164a8 W vsscanf
How can I debug this? For first I wanted to understand what exactly GCC is using for linking (I'm linking through GCC). I know that if symbol is found in a text segment, the
whole segment is used, but still that's too much.
Any suggestion on how to tackle this would really be appreciated.
Thanks
Using GCC's -v and -Wl,-v options will show you the linker commands (and version info of the linker) being used.
Which version of GCC are you using? I made some changes for GCC 4.6 (see PR 44647 and PR 43863) to reduce code size to help embedded systems. There's still an outstanding enhancement request (PR 43852) to allow disabling the inclusion of the IO symbols you're seeing - some of them come from the verbose terminate handler, which prints a message when the process is terminated with an active exception. If you're not using execptions then some of that code is useless to you.
The problem is not about the STL, it is about the Standard library.
The STL itself is pure (in a way), but the Standard Library also includes all those streams packages and it seems that you also managed to pull in the libc as well...
The problem is that the Standard Library has never been meant to be picked apart, so there might not have been much concern into re-using stuff from the C Standard Library...
You should first try to identify which files are pulled in when you compile (using strace for example), this way you can verify that you only ever use header-only files.
Then you can try and remove the linking that occurs. There are options to pass to gcc to precise that you would like a standard library-free build, something like --nostdlib for example, however I am not well versed enough in those to instruct you exactly here.

Is it possible to symbolicate C++ code?

I have been running into trouble recently trying to symbolicate a crash log of an iOS app. For some reason the UUID of the dSYM was not indexed in Spotlight. After some manual search and a healthy dose of command line incantations, I managed to symbolicate partially the crash log.
At first I thought the dSYM might be incomplete or something like that, but then I realized that the method calls missing were the ones occurring in C++ code: this project is an Objective-C app that calls into C++ libraries (via Objective-C++) which call back to Objective-C code (again, via Objective-C++ code). The calls that I'm missing are, specifically, the ones that happen in C++ land.
So, my question is: is there some way that the symbolication process can resolve the function calls of C++ code? Which special options do I need to set, if any?
One useful program that comes with the apple sdk is atos (address to symbol). Basically, here's what you want to do:
atos -o myExecutable -arch armv7 0x(address here)
It should print out the name of the symbol at that address.
I'm not well versed in Objective-C, but I'd make sure that the C++ code is being compiled with symbols. Particularly, did you make sure to include -rdynamic and/or -g when compiling the C++ code?
try
dwarfdump --lookup=0xYOUR_ADRESS YOUR_DSYM_FILE
you will have to look up each adress manually ( or write a script to do this ) but if the symbols are ok ( your dSym file is bigger than say 20MB) this will do the job .

How do I check for an unmangled C++ symbol when building a PHP extension?

I have a PHP module written in C++, which relies on a C++ library (Boost Date_Time) being installed.
Currently, in my config.m4 file I'm checking for the library as follows:
LIBNAME=boost_date_time
LIBSYMBOL=_ZN5boost9gregorian9bad_monthD0Ev
PHP_CHECK_LIBRARY($LIBNAME,$LIBSYMBOL,,
[
AC_MSG_ERROR([lib $LIBNAME not found. Try: sudo apt-get install libboost-dev])
],[
-lstdc++ -ldl
])
Now, this works in my current environment, but I'm painfully aware this will probably break on a different version of the library or compiler.
How can I get automake to understand the non-mangled C++ symbol?
Edit:
I realise that checking on the mangled name is horrible, but is there not some way of checking for the symbol name as returned by "nm -C" (eg boost::gregorian::bad_month etc).
I found some refence to the automake command AC_LANG_CPLUSPLUS(), but I'm not sure how to use it and whether it's applicable here.
You can check AC_TRY_COMPILE with something like that:
LIBNAME=boost_date_time
AC_MSG_CHECKING([for BOOST])
AC_TRY_COMPILE(
[
#include "boost/date_time/gregorian/greg_month.hpp"
],
[
boost::gregorian::bad_month* bm = new boost::gregorian::bad_month;
],
[
AC_MSG_RESULT(yes)
],
[
AC_MSG_ERROR([lib $LIBNAME not found. Try: sudo apt-get install libboost-dev])
])
This avoid the use of unmangled symbol.
Outside of the environment of a particular C++ compiler, there is no "non-mangled C++ symbol" - the mangling is done precisely to provide a unique name to external tools, such as linkers and librarians.
This is a terrible idea -- to have mangled symbols out in the open. Why'd you need this in the first place?
Having seen your update, I'd have to ask, why not use a custom rule to invoke nm and get this information and make this rule to be passed as a requirement? I would be very surprised if autoconf was to provide a direct command to check object files for symbols.
You need to provide a set of C++ wrappers for the Boost api functions that you wish to invoke. These wrappers need to be declared with extern "C", as in:
extern "C"
void foo(int bar)
{
...
}
Your PHP code should use these wrappers, rather than trying to directly call C++ methods.
EDIT: Since you're assuming the availability of automake, you're probably planning to compile the Boost library as part of the install. This gives you the option of probing the result of the name mangling. Try creating a test C++ program along these lines. Note that this only needs to compile; it doesn't need to produce a valid result.
#include "boost/date_time/gregorian/greg_month.hpp"
int main( int argc, const char* argv[] )
{
boost::gregorian::bad_month* xxxjunk = new boost::gregorian::bad_month;
return 0;
}
In your automake, you'd want to compile this, then run the output through
nm -C | grep "boost::gregorian::bad_month"
Depending on your needs and pickiness, you might want to further refine the grep command to look for the string "typeinfo for boost::gregorian::bad_month" (note that this further increases your dependency on the specific compiler implementation.)