I'm working on GCC112 from the compile farm, which is a Linux ppc64-le machine. I'm testing IBM XL C/C++ and catching a compile failure on some AES code that uses POWER8. The code has worked for the last couple of years. The failure is new.
The compile failure is:
$ CXX=xlC make aes-simd.o
xlC -DNDEBUG -g2 -O3 -qrtti -qpic -qarch=pwr8 -qaltivec -c aes-simd.cpp
In file included from aes-simd.cpp:29:
./ppc-simd.h:443:16: error: use of undeclared identifier
'__builtin_crypto_vcipher'; did you mean '__builtin_vec_vcipher'?
return (T1)__builtin_crypto_vcipher((uint64x2_p)state, (uint64x2_p)key);
__builtin_crypto_vcipher is a GCC builtin. The only way to get into that path is if __xlc__ and __xlC__ are not defined:
template <class T1, class T2>
inline T1 VectorEncrypt(const T1& state, const T2& key)
{
#if defined(__xlc__) || defined(__xlC__)
return (T1)__vcipher((uint8x16_p)state, (uint8x16_p)key);
#elif defined(__GNUC__)
return (T1)__builtin_crypto_vcipher((uint64x2_p)state, (uint64x2_p)key);
#else
_ASSERT(0);
#endif
}
Checking preprocessor macros:
$ xlC -qshowmacros -qarch=pwr8 -qaltivec -E aes-simd.cpp | grep -i xlc
#define __XLC_BUILTIN_VAARG__ 1
It looks like nearly all the preprocessor macros have disappeared. A single macro of __XLC_BUILTIN_VAARG__ is not correct.
What happened to the IBM XL C/C++ preprocessor macros, and how do I get them back?
$ xlC -qversion
IBM XL C/C++ for Linux, V13.1.6 (Community Edition)
Version: 13.01.0006.0001
/opt/ibm/xlC/13.1.6/bin/.orig/xlC
IBM XL C/C++ for Linux V13.1.6 does not define __xlc__ or __xlC__ by default, but you can get the compiler to define them by using -qxlcompatmacros. You may be able to make use of the other macros it defines like __ibmxl__; see this Knowledge Center page for more information.
I know the GCC compile farm admins recently upgraded to 13.1.6 at the request of one of XL's other users, but I believe IBM XL C/C++ for Linux (for little endian distributions) has always had this same behaviour.
IBM XL C/C++ for Linux (for big endian distributions) and IBM XL C/C++ for AIX behave differently and define __xlc__ or __xlC__ by default.
Related
The musl C library has only an approximative implementation of symbol versioning. This can result in symbols being bound together that have different symbol versions, something which would not happen in a full implementation. Projects which expect to be built with musl are therefore better off with avoiding symbol versioning altogether. (Not supporting symbol versioning is by itself not necessarily a bad choice for a toolchain; it all depends on the target audience.)
However, the Alpine Linux toolchain compiles binutils with full symbol versioning support: GAS suppports the .symver directive, and the link editor handles version scripts and assigns symbol versions (just as it would on GNU/Linux). A simple compiler/assembler or linker check shows that symbol versioning is supported. As a result, some of the shared objects which Alpine Linux includes in the distribution do in fact use symbol versioning, although the musl dynamic loader will ignore this data. (The data just bloats the binaries.)
In some cases, software fails to run (after building just fine) because it uses compatibility symbols (symbols without a default version) in ways that are not supported by the musl dynamic linker. Here's a small example of what does not work:
cat > symver.c <<EOF
void
compat_function (void)
{
}
__asm__ (".symver compat_function,compat_function#SYMVER");
void
call_compat_function (void)
{
return compat_function ();
}
EOF
echo "SYMVER { };" > symver.map
cat > main.c <<EOF
extern void call_compat_function (void);
int
main (void)
{
call_compat_function ();
}
EOF
gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c
gcc -Wl,--rpath=. -o main main.c symver.so
./main
Execution fails with Error relocating ./symver.so: compat_function: symbol not found. It runs successfully without the .symver directive.
How is this combination of binutils support for symbol versioning in combination with a dynamic linker that does not support it supposed to work in practice? Should projects check for a *-musl target triplet and disable symbol versioning?
A run-time check for dynamic linker support would do the job, but it would break cross-compiling. Should this be fixed in Alpine Linux itself, by disabling symbol versioning support in binutils?
I have written a programm in C and GTK3. I am using Arch Linux and everything works fine. However, I have to use my program also on a rather old Ubuntu machine.
gtk+-3.0 3.10.8
GCC 4.8.4
With this setup the program does not compile
In the Header file of a custom GTK-Widget I have:
#ifndef __LAYER_ELEMENT_H__
#define __LAYER_ELEMENT_H__
#include <gtk/gtk.h>
G_BEGIN_DECLS
G_DECLARE_FINAL_TYPE(LayerElement, layer_element, LAYER, ELEMENT, GtkListBoxRow)
/* Rest of file comes here */
When compiling it throws the error message:
expected ')' before GtkListBoxRow in the line with the G_DECLARE_FINAL_TYPE macro.
How can I fix this issue?
G_DECLARE_FINAL_TYPE was added to GLib in version 2.44 (see the documentation). If you want to compile on an old version of Ubuntu, you will either have to get hold of a backport of GLib 2.44 (or later) for that version of Ubuntu, and compile against that; or you will have to modify your code to not use any GLib APIs added after version 2.40.
Good old disconnect between what the compiler deems valid and what the IDE thinks... Before you introduce duplicate questions / answers, I must stress that everything available on the issue here and elsewhere I have already tried and distilled to this setup:
install latest eclipse CDT - Oxygen 4.7.2 / build id 20171218-0600
gcc 6.1 only compiler visible in system path - defaults to c++14 standard without the need for explicit -std flag
Checking the log for compiler settings discovery, it's configured correctly for C++14:
03:51:39 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
g++ -E -P -v -dD C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-6.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/lib -L/c/mingw610/prerequisites/x86_64-zlib-static/lib -L/c/mingw610/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 6.1.0 (x86_64-posix-seh, Built by MinGW-W64 project)
COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-shared-libgcc' '-mtune=core2' '-march=nocona'
C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/6.1.0/cc1plus.exe -E -quiet -v -P -iprefix C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/ -D_REENTRANT C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -mtune=core2 -march=nocona -dD
#define __STDC__ 1
#define __cplusplus 201402L
(etc)
The following snippet compiles (with unused variable warning but nonetheless), but eclipse highlights issues with resolving test in int main:
auto test (auto N) {return N;}
int main () {
auto z = test( 3U );
return 0;
}
The parser log gives:
Unresolved names:
Attempt to use symbol failed: test in file ...
The IDE shows this in problems:
Invalid arguments '
Candidates are:
? test(?)
'
For all intents and purposes eclipse is in fact seeing the correct gcc binary, and is using the correct c++ standard, but still not conforming to the compiler per evidence above (unless I missed something?).
Any ideas how to make eclipse behave with syntax parsing given it's already got the right c++ standard version?
I get the feeling it's an issue with the indexer rather than the parser, since it has no trouble figuring out the number of arguments or the declaration but can't seem to make sense of functions with auto return type that depends on an auto-typed argument.
UPDATE
It may be related to this bug (looks to be fixed) and this followup bug (still ongoing, test case given is similar to mine).
However, this version of test does not give me problems, so I'm unsure if it's the same bug or something else...
template< typename T > auto test (T N) {return N;}
auto in the parameter type of a function (as opposed to a lambda) is not standard C++14.
It's supported by the Concepts TS (which is supported by GCC >= 6 with the -fconcepts flag), and accepted by GCC >= 4.9 even without -fconcepts as an extension, but it's not standard. (It may become standard in C++20, along with some other parts of the Concepts TS.)
For example, here's what Clang (which does not support this extension) says about your code in C++14 mode:
test.cpp:1:12: error: 'auto' not allowed in function prototype
auto test (auto N) {return N;}
^~~~
Eclipse CDT does not currently implement this extension either. I filed bug 532085 to track adding support for it; contributions are welcome!
I am trying to get started using Rccp and decided to use Eclipse as a development environment since I already use StatEt for R. I am having trouble getting even a simple program to compile and run though, and would appreciate some help!
Briefly I tried to follow the instructions on the blog: http://blog.fellstat.com/?p=170 exactly for setting up Rcpp, RInside and Eclipse, and for the example program. I am running on Mountain Lion, and installed g++ using the command line options in XCode. I think I've faithfully followed all the steps in the blog, but cannot get the program to compile. I think the problem is in the way the header files are included, as indicated from the snippet of the output below. As far as I can tell, line 52 of /usr/include/c++/4.2.1/cstring is an include statement for <string.h> and the compiler includes Rccp/include/string.h instead of the string.h from std that is found earlier on the include path.
I am a novice in C++ so I'd really appreciate some pointers on how to proceed.
-Krishna
16:22:38 **** Incremental Build of configuration Debug for project MyTestRCppPackage ****
Info: Internal Builder is used for build
g++ -DINSIDE -I/Library/Frameworks/R.framework/Versions/2.15/Resources/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include -O0 -g3 -Wall -c -fmessage-length=0 -arch x86_64 -v -o src/main.o ../src/main.cpp
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/cc1plus -quiet -v -I/Library/Frameworks/R.framework/Versions/2.15/Resources/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include -imultilib x86_64 -iprefix /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -dD -D__DYNAMIC__ -DINSIDE ../src/main.cpp -fPIC -quiet -dumpbase main.cpp -mmacosx-version-min=10.8.3 -m64 -mtune=core2 -auxbase-strip src/main.o -g3 -O0 -Wall -version -fmessage-length=0 -D__private_extern__=extern -o /var/folders/hc/vqp48jt56_v332kc3dqyf5780000gn/T//ccqdmOKI.s
ignoring nonexistent directory "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin11/x86_64"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
/Library/Frameworks/R.framework/Versions/2.15/Resources/include
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include
/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) (i686-apple-darwin11)
compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=65536
Compiler executable checksum: b37fef824b01c0a99fb2679acf3b04f1
In file included from /usr/include/c++/4.2.1/cstring:52,
from /usr/include/c++/4.2.1/bits/stl_algobase.h:66,
from /usr/include/c++/4.2.1/memory:53,
from /usr/include/c++/4.2.1/tr1/hashtable:56,
from /usr/include/c++/4.2.1/tr1/unordered_map:37,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/platform/compiler.h:158,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/RcppCommon.h:26,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp.h:27,
from ../src/main.cpp:8:
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: 'internal' has not been declared
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: typedef name may not be a nested-name-specifier
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: expected ';' before '<' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:65: error: expected `)' before 'charsxp'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:70: error: expected ',' or '...' before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: expected unqualified-id before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: expected ',' or '...' before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: 'Rcpp::String::String()' cannot be overloaded
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:55: error: with 'Rcpp::String::String()'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:85: error: 'Rcpp::String::String(int)' cannot be overloaded
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:70: error: with 'Rcpp::String::String(int)'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:88: error: expected `)' before 'x'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:89: error: expected `)' before 'x'
There are two entirely separate issues here:
Get all you need for Rcpp installed. OS X aspects should be documented on the relevant page maintained by Simon. If you have the tools, and have Rcpp install, then you should be able to do cppFunction('double nPi(int x) { return x*M_PI; }') which is uses functions supplied with Rcpp to create a callable C++ functions accessible to you as nPi() -- and nPi(2) should return a value.
Your choice of IDE and its settings. This is has little to do with 1. apart from requiring it to work to.
So I would work on 1. and see if I got that sorted out first, and only then turn to 2.
To summarize, the issue I faced was that include files in Rcpp with the sames names as those in std were in conflict. In particular, string.h from Rcpp was being included at a point where string.h from std was the right choice, and, as far as I could tell, this was due to the fact that paths specified via the -I directive are searched prior to the default paths.
I tried many different alternatives to solve this, including removing and re-installing XCode and the associated Command Line tools, as well as installing another g++ compiler using macports. None of these resolved the issue. I then used the -idirafter directive instead of the -I directive for the search path for include files for Rcpp and R. I got this hint from gcc include order broken?. This worked since these directories are now searched after the default paths. This precludes (at least so far!) the possibility that string.h from std and string.h from Rcpp come into conflict.
To get step 5 of http://blog.fellstat.com/?p=170 to work I had to set the -idirafter paths in PKG_CPPFLAGS in the file Makevars.
Thanks to everyone for your suggestions.
You simply have to remove include
/Library/Frameworks/R.framework/Resources/library/Rcpp/include/Rcpp
because it is:
unnecessary, as all R imports are in form <Rcpp/XXX>
causes this issue, as compiler looks for string.h in Rcpp directory (when it shouldn't).
Update
Thank you Vladimir for the usefull insights in libraries. I took another approach, developping first in ubuntu (which was a lot easier then messing around with Eclipse/Cygwin/... and now I'm trying to port to windows, which goes rather ok, however I have some questions about that too, posted here: Problems with porting a fortran program from ubuntu to windows
Question
I currently have the following setup and can't get the lapack library configured so that my fortran code can compile:
Windows 7
Cygwin installation (for GNU fortran), added to the windows PATH
lapack and liblapack-devel installed with cygwin
resulting in liblapack.a and libblas.a in the folder C:/cygwin/lib
In my program I call the lapack library using the following code
program myProgram
!use lapack (stays commented now)
...
In Eclipse I used the following setup (with the Photran package):
Fortran Project: executable GNU fortran on Windows (GCC toolchain)
GNU fortran compiler: gfortran ${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
GNU fortran linker: gfortran ${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
I compiled the libraries libblas.a and liblapack.a, to use as a static library, for windows and they are located in the C:/cygwin/lib folder. In the GNU fortran linker properties, the libraries were called lapackand blasin the folder C:/cygwin/lib. This results in a part -L"C:/cygwin/lib" -llapack -lblas in the {$COMMAND} section of the compiler and linker. (thanx to #vladimir-f for the help)
In the output there are no error messages left anymore. Only I got now the following error in Eclipse and no final .exe or bins:
Errors occured during the build.
Errors running builder 'CDT Builder' on project 'Hamfem'
Internal error building project Hamfem configuration
Release
java.lang.NullPointerException
Internal error building project Hamfem configuration
Release
java.lang.NullPointerException
However, the result of the build is still an executable, in this case called Hamfem.exe. Running this file results in the error message (instead of the routine): The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
That file is currently located in C:/cygwin/lib/lapack/ but I want that this file isn't needed to run the program, so I can run it on different computers. Can someone collaborate on this?
Second, when copy-pasting the .dll file in the folder where the .exe is located, it runs for a brief second, generating a stackdump file. I can't use the debugger in Eclipse-Photran due to the 'Building Workspace' error. Eclipse gives the message Binary not found when I want to run it in Eclipse as a local Fortran program. Any ideas how to resolve this problem?
The problem is here
L/lib/lapack –llapack
try to change it for
-L/lib/lapack –llapack
probably it is in you Makefile.
i.e.
gfortran -funderscoring -O3 -Wall -c -fmessage-length=0 -L/lib/lapack -llapack -o
And make sure lapack.mod is really in /lib/lapack which is probably C:\cygwin\lib\lapack on Cygwin.