I am on a 64 bit CentOS 6.7 machine with g++ 4.4.7 and I am trying to compile the ACE TAO library 1.2 that was compiled with g++ 2.96.
When I try to compile using the g++ version 4.4.7 I get the following errors (more complete output here
g++ -W -Wall -Wpointer-arith -pipe -O3 -g -Wno-uninitialized -fno-implicit-templates -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT -I/home/oscarpelaoo/Downloads/ACE_wrappers -DACE_HAS_EXCEPTIONS -c -fPIC -o .shobj/URL_Addr.o URL_Addr.cpp
In file included from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/ACE.h:17,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/INET_Addr.h:17,
from URL_Addr.h:20,
from URL_Addr.cpp:3:
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS.h:3110:27: error: new.h: No such file or directory
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/backward/strstream:47,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/streams.h:70,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS.h:3197,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/ACE.h:17,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/INET_Addr.h:17,
from URL_Addr.h:20,
from URL_Addr.cpp:3:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/backward/backward_warning.h:28:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
In file included from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.h:191,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS.h:38,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/ACE.h:17,
from /home/oscarpelaoo/Downloads/ACE_wrappers/ace/INET_Addr.h:17,
from URL_Addr.h:20,
from URL_Addr.cpp:3:
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl: In static member function ‘static int ACE_OS_TLI::t_accept(ACE_HANDLE, ACE_HANDLE, t_call*)’:
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl:12: warning: the address of ‘call’ will never be NULL
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl:13: warning: the address of ‘reshandle’ will never be NULL
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl:14: warning: the address of ‘handle’ will never be NULL
/home/oscarpelaoo/Downloads/ACE_wrappers/ace/OS_TLI.inl: In static member function ‘static char* ACE_OS_TLI::t_alloc(ACE_HANDLE, int, int)’:
After a bit of research, I found that Red Hat offers some old libstdc++ libraries for CentOS 6 here.
Is it possible to use an old version of g++ 2.96 which I don't believe has 64 bit support or can I somehow use the compatibility tools with g++ 4.4.7 to try to make something happen?
Answering my own post since I was able to install it.
After installing the relevant 32bit libraries, the -m32 flag needed to get added. Then we needed to add a -DACE_LACKS_NEW_H flag since my system does not contain the <new.h> file. After that I just needed add a forward declaration and the library compiled.
Related
I have tried to install kannel 1.4.5 in centos 7 but when run make command getting below error.
gcc -std=gnu99 -D_REENTRANT=1 -I. -Igw -g -O2 -D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_LARGE_FILES= -I/usr/include/libxml2 -I/usr/include/openssl -o wmlscript/wslexer.o -c wmlscript/wslexer.c
wmlscript/wslexer.c:221:32: error: unknown type name ‘YYLTYPE’
int ws_yy_lex(YYSTYPE *yylval, YYLTYPE *yylloc, WsCompiler* compiler)
^
make: *** [wmlscript/wslexer.o] Error 1
The version of Bison used by CentOS isn't compatible with this code. According to a bug report on this issue,
the problem occurs because bison 3 no longer supports YYLEX_PARAM and YYPARSE_PARAM. Both were have been deprecated since version 1.875, which was released on January 1, 2003
Not sure why it wasn't fixed in the latest release, but you can either downgrade to Bison 2.7 or apply this patch (linked from the bug report) to the code. The patch will:
remove YYLEX_PARAM and YYPARSE_PARAM #defines
add %lex-param and %parse-param directives
change all uses of void* pctx to WsCompiler* compiler
remove unnecessary casts from void* to WsCompiler*
modify the declaration of yyerror and move the declaration below %union so that it will have access to YYLTYPE.
I recently updated my Linux laptop from Ubuntu 16.04 to 18.04.
I had a STM32 (Cortex-M4) Makefile based project that compiled correctly with the arm-none-eabi g++ version provided by Ubuntu. The generated file required 47620 bytes in the .text section.
With the Ubuntu upgrade, I have also installed an up-to-date version of gcc (from ARM website). Version is 8.2.1.
When I compile the same project (make clean && make), the generated binary do not fit in flash (97424 bytes required, more than twice!). The project is exactly the same (sources, link script, startup files, Makefile).
The compiler options are: -mthumb -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -DSTM32F303x8 -DARMCM4 -O0 -g -Wall -fexceptions -Wno-deprecated.
The linker options are -mthumb -mcpu=cortex-m4 -Tstm32f303K8.ld -mfloat-abi=hard -mfpu=fpv4-sp-d16 --specs=nosys.specs -lm -Wl,--start-group -lm -Wl,--end-group -Wl,--gc-sections -Lsys -Xlinker -Map=test.elf.map
When I look at the .Map generated file, all the user functions take approximatively the same size (new version saves 8 bytes!). But after, it includes C++ sepcific parts, and one is more than 26Kb (from map file):
.text 0x00000000080079e8 0x683c /usr/local/gcc-arm-none-eabi-8-2018-q4-major/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libstdc++.a(cp-demangle.o)
0x000000000800e13c __cxa_demangle
Note: there is no problem with C only projects, only with C++. The library included are the same (gcc 4.9.3 -> armv7e-m/fpu, and gcc 8.2.1 -> thumb/v7e-m+fp/hard):
libm.a libstdc++.a libc.a libnosys.a libgcc.a
Is there a way to get rid of that so that I can compile and flash my (no so old) project?
regards,
I found a solution using the libstdc++_nano (instead of implicit libstc++). With that, the code size is reduced from 84kb to 26kb!
LDFLAGS += -lstdc++_nano
It just works. Thanks #Henrik, #Matthieu and #EOF for your support!
It might be related to exception handling, as std::terminate(), which is used with exceptions, might call the demangling routine. If you don't need exceptions then try disabling them with -fno-exceptions as described here.
Another solution might be to look at the GCC headers:
Demangling routine.
ABI-mandated entry point in the C++ runtime library for demangling.
[...]
returns a pointer to the start of the NUL-terminated demangled
name, or NULL if the demangling fails. The caller is
responsible for deallocating this memory using free.
The prototype is:
char*
__cxa_demangle(const char* __mangled_name, char* __output_buffer,
size_t* __length, int* __status);
So you could probably just supply your own dummy function returning NULL (Given that all library functions are weak, and can be overridden). I'll advise you to look at the disassembled code first though, and find out how and why it is being called in the first place, since it might change behaviour to just discard functionality).
They also give other advise in This forum post, which might be useful for you as well:
Optimize for size with -Os instead of -O0 (possibly add the -Og option instead, if you prefer easily debuggable code, it is often both smaller and faster than -O0).
Optimize at link-time with -flto while compiling and linking.
Maybe disable RTTI if not used.
The Questions
I have a few questions surrounding usage of Intel Pin with C++14 or other C++ verions.
There are rarely any problems compiling code from older C++ with newer versions, but since Intel Pin is manipulates instruction level, is there any undesirable side effects that might come if I compile it with C++11 or C++14?
If it's ok to compile with C++11 or C++14, how do I make a rule to enable a newer version of C++ for my tool only?
How do I set GCC/G++ default C++ version to latest, if possible, and what should I keep in mind when doing so?
Situation
I'm building a dynamic call graph pin tool. To make it understandable, I'm computing the depth of the call stack. For safety, I decided to wrap the excerpt of code that increments or decrements the depth with a std::mutex. This has gotten me to the problem that std::mutex is available only since C++11, which is not Intel Pin default in my machine.
$ g++ -v
[...]
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)
Compile command:
$ make obj-intel64/callgraph.so
[...]
error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support
[...]
EDIT
I managed to make a build rule that defines version to C++11, but it breaks. The command sent to g++ through make was
g++ -DBIGARRAY_MULTIPLIER=1 -Wall -Werror -Wno-unknown-pragmas -D__PIN__=1
-DPIN_CRT=1 -fno-stack-protector -fno-exceptions -funwind-tables
-fasynchronous-unwind-tables -fno-rtti -DTARGET_IA32E -DHOST_IA32E -fPIC
-DTARGET_LINUX -fabi-version=2 -I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/source/include/pin
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/source/include/pin/gen
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/stlport/include
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/libstdc++/include
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include/arch-x86_64
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include/kernel/uapi
-isystem /home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/crt/include/kernel/uapi/asm-x86
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/components/include
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/xed-intel64/include
-I/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/source/tools/InstLib -O3
-fomit-frame-pointer -fno-strict-aliasing -std=c++11
-c -o obj-intel64/callgraph.o callgraph.cpp
This doesn't compile. Instead, it'll fall into a huge error log inside STL headers. It appears that Pin comes along with it's own subset of STL, that conflicts with C++11 and C++14. I've uploaded a paste of the g++ output. It filled 2331 lines, but I've noticed that strange thing in the folders it visits. STL libraries are included from 2 different directories:
/usr/include/c++/5/
/home/gabriel/Downloads/pin-3.0-76991-gcc-linux/extras/stlport/include/
Solving errors one-by-one is unfeasible, deleting pin stl port probably is an even worse idea. If it's possible to use Pin with newer C++, I'd say simple std=c++1y is not the way.
From the compiler options used to compile the pin tool, I presume you are using the latest version of Pin, namely 3.0. According to Intel, the CRT that ships with the framework doesn't support C++11 and later versions of the language. In particular, you will not be able to use any of the APIs supported in C++11 including std::mutex. If it's critical for you to use C++11 APIs then you should use the previous version of Pin, namely 2.14, which doesn't ship with a CRT and uses the CRT of your compiler.
However, if all you want is a mutex, you can use the OS-portable mutex that ships with Pin 3.0. For more information, refer to the documentation.
When using Pin 3.0 you are not allowed to use any header file or object file of your compiler (those from /usr/include/c++/5/). You can only use PinCRT and few system header files.
I have made an OpenGL project compilable with GCC (version 4.7.3 and newer) and runable on Linux. When trying to compile the same code under Windows using MSYS2 with GCC 4.9.2 installed, I get tons of error reports:
g++ -g --std=c++11 src/*.cpp -Iinclude -Isrc -lIL -lILU -lILUT -lGL -lGLU -lglut -lm -DWIN32 -I/mingw64/include windows/src/*.cpp -o "Achtung, die Kurve 3D!"
In file included from /usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/stringfwd.h:40:0,
from /usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/string:39,
from include/windows.h:1,
from /usr/include/w32api/GL/gl.h:13,
from /mingw64/include/GL/freeglut_std.h:143,
from /mingw64/include/GL/freeglut.h:17,
from src/controls.cpp:1:
/usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/memoryfwd.h:63:3: error: template with C linkage
template<typename>
^
/usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/memoryfwd.h:66:3: error: template specialization with C linkage
template<>
^
/usr/lib/gcc/x86_64-pc-msys/4.9.2/include/c++/bits/memoryfwd.h:70:3: error: template with C linkage
template<typename, typename>
^
...
In file included from /mingw64/include/GL/freeglut_std.h:143:0,
from /mingw64/include/GL/freeglut.h:17,
from src/controls.cpp:1:
/usr/include/w32api/GL/gl.h:684:1: error: ‘WINGDIAPI’ does not name a type
WINGDIAPI void APIENTRY glAccum(GLenum op,GLfloat value);
...
/usr/include/w32api/GL/gl.h:1037:24: error: expected ‘)’ before ‘*’ token
typedef void (APIENTRY *PFNGLGETCOLORTABLEPARAMETERFVEXTPROC)(GLenum target,GLenum pname,GLfloat *params);
^
In file included from /mingw64/include/GL/freeglut_std.h:144:0,
from /mingw64/include/GL/freeglut.h:17,
from src/controls.cpp:1:
/usr/include/w32api/GL/glu.h:24:25: error: expected initializer before ‘gluErrorString’
const GLubyte *APIENTRY gluErrorString(GLenum errCode);
^
/usr/include/w32api/GL/glu.h:25:25: error: expected initializer before ‘gluErrorUnicodeStringEXT’
const wchar_t *APIENTRY gluErrorUnicodeStringEXT(GLenum errCode);
^
...
This is taken from just a partial log consisting of 4500 lines of errors. These are the most frequent ones repeated many times.
I previously thought that the problem lied in old MSYS/MinGW (not the MSYS2 port) which I tried first with the same results. However, MSYS2 did not solve the problems which makes me completely clueless since my code is written in C++ and it only requires standard C and C++ header files along with some GL ones. I do not use any extern "C" mangling.
You are using msys2 GCC here, not mingw-w64 GCC.
Please read the MSYS2 wiki [1] where all of this is explained, but briefly:
Run mingw64_shell.bat, not msys2_shell.bat, install the mingw-w64 GCC toolchain package(s). This command installs both the 32-bit and 64-bit ones using the bash curly brace expansion feature:
pacman -S mingw-w64-{x86_64,i686}-toolchain
.. then see that gcc -dumpmachine reports x86_64-w64-mingw32 and not x86_64-pc-msys
[1] https://sourceforge.net/p/msys2/wiki/Home/
The problem turned out not to be related to OpenGL, neither to MSYS(2)/MinGW(-w64) or MS Visual Studio 2013.
For anyone who might be facing the same problems as I was, the vast majority of all the error reports was generated because there was a custom windows.h header file present in my project's include path. A header with the same name is present in standard Windows header library and is essential for proper functionality of other libraries.
Lesson learned: never try to name a file with system-specific code after the operating system.
GoogleTest 1.6 with Cygwin 1.7: 'fileno' was not declared in this scope
Error message when building a simple test on Factorial() function in Eclipse CDT:
Invoking: Cygwin C++ Compiler
g++ -std=c++0x -DGTEST_OS_CYGWIN=1 -I"E:\source\gtest-1.6.0\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/challenge.d" -MT"src/challenge.d" -o "src/challenge.o" "../src/challenge.cpp"
In file included from E:\source\gtest-1.6.0\include/gtest/internal/gtest-internal.h:40:0,
from E:\source\gtest-1.6.0\include/gtest/gtest.h:57,
from ../src/challenge.cpp:11:
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h: In function 'int testing::internal::posix::FileNo(FILE*)':
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1589:51: error: 'fileno' was not declared in this scope
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1595:57: error: 'strdup' was not declared in this scope
E:\source\gtest-1.6.0\include/gtest/internal/gtest-port.h:1627:71: error: 'fdopen' was not declared in this scope
Eclipse CDT 8.1 running gcc 4.7.3 on Cygwin 1.7.22
gTest 1.6 succesfully built including demo tests, with cmake 2.8.9 on Cygwin 1.7.22
I've linked the built lib with full path, E:\lib\gtest-1.6.0\Cygwin\libgtest.a
The following command option was added manually, got same error without it.
-DGTEST_OS_CYGWIN=1
Seems the errors have nothing to do with my code. Anyone using gTest with Eclipse and Cygwin?
Thank you,
unsigned long Factorial(unsigned n) {
return n==0? 0 : n*Factorial(n-1);
}
// Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
EXPECT_EQ(1, Factorial(0));
}
// Tests factorial of positive numbers.
TEST(FactorialTest, HandlesPositiveInput) {
EXPECT_EQ(1, Factorial(1));
EXPECT_EQ(2, Factorial(2));
EXPECT_EQ(6, Factorial(3));
EXPECT_EQ(40320, Factorial(8));
}
Setting the C++ standard to -std=gnu++0x rather than -std=c++0x, worked for me. You can try the statement:
g++ -std=gnu++0x -DGTEST_OS_CYGWIN=1 -I"E:\source\gtest-1.6.0\include" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/challenge.d" -MT"src/challenge.d" -o "src/challenge.o" "../src/challenge.cpp"
Setting symbol (-DGTEST_OS_CYGWIN=1) has got nothing to do with this error.
Some functions go beyond the ANSI standard.
These are disabled when you use std=c++11 (or std=c++0x).
Among them are fdopen, fileno and strdup.
There are two possibilities to use them:
Use the GNU dialect (std=gnu++11).
If you want to compile without dialect and make a local exception, you can include stdio.h with the __STRICT_ANSI__ undefined. (see: Error "'fdopen' was not declared" found with g++ 4 that compiled with g++3)
I have tested both on Suse Linux Enterprise 11, MinGW and Cygwin.
Addition: Another (possibly better) way to access non-ANSI symbols would be to add
#define _POSIX_C_SOURCE 200809L
before the first #include in your file. This will give you access to most of the non-standard routines.
Some functions (e.g. realpath(...)) require
#define _BSD_SOURCE
to be inserted on top of your file.