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.
Related
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.
Having installed LLVM on Ubuntu 16.04 using the command:
sudo apt-get install clang llvm
I get the following error when compiling:
nlykkei#nlykkei-VirtualBox:~$ clang++ -g toy.cpp `llvm-config --cxxflags --ldflags --system-libs --libs` -o toy
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
'-Wno-uninitialized'? [-Wunknown-warning-option]
1 warning generated.
To be specific, I follow the tutorial: http://llvm.org/docs/tutorial/LangImpl03.html on the LLVM website.
The version of LLVM is 3.8.
How do I get rid of this warning?
Thanks.
This is a bug in llvm-config. Long story short, llvm-config outputs -Wno-maybe-uninitialized which is not a warning implemented by clang.
One possible workaround is to add an extra flag squelching warnings about unknown warnings.
clang++ <your flags> -Wno-unknown-warning-option `llvm-config ...`
This warning comes when you recently upgraded your sdk-build-tools with 30.x
I resolved the issue by downgrading sdk-build-tools by 29.x.
Delete all the intermediate files , they will be auto generate again.
Clean Project .
Invalidate Cashes and Restart the Project.
Woow, warning has been removed now.
Answer mentioned here https://github.com/envoyproxy/envoy/issues/18986 might help. Mostly changing Wno-maybe-uninitialized with -Wno-uninitialized in / bazel/envoy_internal.bzl
I am trying to compile yap on my PC since it seems YAP default installers don't come with the Depth limit flag enabled. I need this to work on an ILP project on Aleph.
The thing is, that I am forced to use a PC with windows 8 without enough memory for a Linux Virtual machine.
I got cygwin to attempt to install it, but once I get to the 'make' stage of the installation ( http://www.dcc.fc.up.pt/~vsc/Yap/Yap4.3/yap.html#SEC2 ) I get this following error
$ make
Makefile:714: warning: overriding recipe for target 'yap.dll'
Makefile:545: warning: ignoring old recipe for target 'yap.dll'
gcc -mno-cygwin -c -O3 -fomit-frame-pointer -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -DCUT_C=1 -DCOROUTINING=1 -DRATIONAL_TREES=1 -DDEPTH_LIMIT=1 -DHAVE_CONFIG_H -D_YAP_NOT_INSTALLED_=1 -I. -I../H -I../OPTYap -I../BEAM -I../MYDDAS ../C/agc.c -o agc.o
gcc: error: unrecognized command line option ‘-mno-cygwin’
Makefile:488: recipe for target 'agc.o' failed
make: *** [agc.o] Error 1
I assume it's due to the latest YAP being outdated right now, does anyone know what to do to work around this?
It seems long time has passed since the question is asked. But I would like to answer since the problem is still relevant (I had this problem lately).
Asking at YAP-users mailing list, I was able to solve this problem. You can check the details here.
In short, using MSYS2 or MinGW-w64 (with toolchain installed) and making few changes in the source code makes it possible.
Changes are:
Adding #include <stdio.h> in blob.c file.
Refactoring H with HEAD (or some other name) in whole project. Which was defined in Regs.h, line 590.
The problem
I am trying to build SRI's Language Modeling tool, srilm version 1.6.0 on my mac, and coming across some fairly strange compilation problems ("strange" in that a few hours of Google-fu did not help), so I am turning to you to see if anyone sees how I can fix this.
I have already checked that I have the required dependencies and followed the install instructions as well as gone through the build troubleshooting section of the FAQ.
System Specifications
I have a pretty vanilla install of OS X, with some packages installed through homebrew. XCode 4.3.2 (latest version) is installed. Here are the other relevant system details.
OS version
Mac OS X 10.7.4
gcc -v printout
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.0.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.6.1/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.6.1 (GCC)
g++ -v printout
$ gcc -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin11.0.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin11.0.0
Configured with: ../gcc-4.6.1/configure --enable-languages=fortran,c++
Thread model: posix
gcc version 4.6.1 (GCC)
uname -a printout
$ uname -a
Darwin MacBook-Air.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
The error itself
The following is the end of the output produced by running make World from the srlim top-level directory. Everything up until this point compiles fine in any of the following circumstances:
I run make World on its own.
I run make World MACHINE_TYPE=macosx
I run make World MACHINE_TYPE=macosx-m64 (specific makefile for 64bit processors)
I run make World MACHINE_TYPE=macosx-m32 (specific makefile for 32bit processors)
And the error that pops up is always the same (shown below).
stderr printout
$ make World
(...) # a bunch of stuff compiles with no errors or warnings
c++ -Wreturn-type -Wimplicit -DINSTANTIATE_TEMPLATES -DHAVE_ZOPEN -I/usr/include -I. -I../../include -DHAVE_ZOPEN -c -g -O2 -fno-common -o ../obj/macosx/LatticeIndex.o LatticeIndex.cc
LatticeIndex.cc:78:6: error: variable length array of non-POD element type
'NBestWordInfo'
makeArray(NBestWordInfo, roundedNgram, len + 1);
^
../../include/Array.h:93:33: note: expanded from macro 'makeArray'
# define makeArray(T, A, n) T A[n]
^
LatticeIndex.cc:126:4: warning: data argument not used by format string
[-Wformat-extra-args]
(float)ngram[0].start);
^
LatticeIndex.cc:128:4: warning: data argument not used by format string
[-Wformat-extra-args]
(float)(ngram[len-1].start + ngram[len-1].duration));
^
2 warnings and 1 error generated.
make[2]: *** [../obj/macosx/LatticeIndex.o] Error 1
make[1]: *** [release-libraries] Error 1
make: *** [World] Error 2
Any idea what could be going wrong? It seems to compile fine on some other people's macs in my department, and I've checked their makefiles for differences, but nothing popped up. No one here has any idea why the build fails, but we'd really appreciate it if you can help us out. Thanks in advance for any help you can provide me with! :-)
The problem is due to Apple using llvm-gcc/clang, which does not support variable length arrays. This problem can actually be addressed by modifying $SRILM/dstruct/src/Array.h, and has been noted and addressed in the upcoming release of srilm.
For the time being, on a mac, build srilm using g++ 4.2 instead, using the following command:
$ make MACHINE_TYPE=macosx-m64 CXX=g++-4.2 World
This builds srilm without problem on all my macs.
I tried googling woht no luck, maybe someone encountered this
I'm using MinGW on my windows 7 32-bit machine (not sure about the version of MinGW, but the g++ version is g++ (GCC) 4.6.1)
I get the following warning for EACH compilation line:
command-line:0:16: warning: missing whitespace after the macro name
example for a compilation line:
g++ -c "-D__XXX_WINDOWS__;" -g -Wall -o "XXX.o" -Isrc "src/YYY.cpp"
The problem is the ; at the end of your -D switch.
The command you give is essentially equivalent to having:
#define foo;
at the to of your source. This does define foo to ;, but that's not valid C99 (and could be a typo). §6.10.3/3 from C99 draft n1124:
There shall be white-space between the identifier and the replacement list in the definition of an object-like macro.
So the compiler warns you, or emits an error if you compile with -std=c99.
(You can probably drop the quotes too once you've removed the semicolon.)