Problems running/compiling root cern code after Mavericks upgrade - c++

I recently upgraded my OS to Mavericks, reinstalled Xcode (upgraded to 5.0.1 from 4.6.2) and also installed xcode-select. Finally I installed root (v5.34/10) again, downloaded the source code from git, and followed the standard ./configure and make. Then source bin/thisroot.sh.
But after following all those steps, code that previously compiled and run is not working any longer.
I'm compiling my code using root libraries, to compile I use as options the output of:
root-config --cflags
root-config --glibs
getting the following:
g++ main.C -pthread -stdlib=libc++ -m64 -I/Users/user/root.git/include -L/Users/royal/root.git/lib -lGui -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lpthread -Wl,-rpath,/Users/user/root.git/lib -stdlib=libc++ -lm -ldl
I tried using both g++ and clang++ and I get the same error:
*** Break *** segmentation violation
Generating stack trace...
--
Warning: /usr/bin/atos is moving and will be removed from a future OS X release.
It is now available in the Xcode developer tools to be invoked via: `xcrun atos`
To silence this warning, pass the '-d' command-line flag to this tool.
--
0x0000000106cee8d7 in main (in a.out) + 1447
--
Warning: /usr/bin/atos is moving and will be removed from a future OS X release.
It is now available in the Xcode developer tools to be invoked via: `xcrun atos`
To silence this warning, pass the '-d' command-line flag to this tool.
--
0x00007fff8e2e95fd in start (in libdyld.dylib) + 1
0x0000000000000001 in <unknown function>
Also I've tried running the code without compiling via root main.C and in this case I get the following:
Error: Ambiguous overload resolution (10001,2) ReactorSpectrumMultiple.h:237:
Calling : getline(ifstream,string);
Match rank: file line signature
ffffffff (compiled) 0 istream& getline(istream&,string&,char);
* 10001 (compiled) 0 istream& getline(istream&,string&);
ffffffff (compiled) 0 basic_istream<char,char_traits<char> >& getline(basic_istream<char,char_traits<char> >&,string&,char);
* 10001 (compiled) 0 basic_istream<char,char_traits<char> >& getline(basic_istream<char,char_traits<char> >&,string&);
*** Interpreter error recovered ***
what is puzzling me even more, as I said before I haven't changed any line of code and this was working perfectly before. I write the lines that trigger the last error in case you see something obvious:
std::string line;
std::ifstream input(IsotopeName);
std::getline(input,line);// This line produces the error
I also tried using getline(input,line); without std::, same error.
Last trial was to write istream::getline(input,line); instead. In that case I get something similar to the first error:
*** Break *** segmentation violation
Generating stack trace...
--
Warning: /usr/bin/atos is moving and will be removed from a future OS X release.
It is now available in the Xcode developer tools to be invoked via: `xcrun atos`
To silence this warning, pass the '-d' command-line flag to this tool.
--
0x000000010e6401d9 in G__getfunction (in libCint.so) + 5929
--
Warning: /usr/bin/atos is moving and will be removed from a future OS X release.
It is now available in the Xcode developer tools to be invoked via: `xcrun atos`
To silence this warning, pass the '-d' command-line flag to this tool.
--
0x000000010e63561b in G__getitem (in libCint.so) + 507
--
I don't copy the whole output since it keeps on printing that warning but triggered by different sources (libCint.so, libCore.so, libRint.so,root.exe and libdyld.dylib)
Thank you for your time.

Related

Can anyone explain how to use OpenACC in GCC?

I am using WSL Ubuntu. And use GCC to compile my C++ code.
I am trying to use OpenACC to parallelize my code. I heard that I can use OpenACC with GCC.
So after I install Ubuntu, I installed GCC.
And then I typed as follows:
$ g++ -fopenacc -o t testfile.cpp
As far as I know, -fopenacc should enable me to use OpenACC inside my code.
However, I got an message saying:
lto-wrapper: fatal error: could not find accel/nvptx-none/mkoffload in /usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/9/:/usr/lib/gcc/x86_64-linux-gnu/ (consider using ‘-B’)
So I guess I missed something.
Does anyone know how to use OpenACC with GCC?
Edited:
I tried:
sudo apt-get install gcc-9-offload-nvptx
And then the error message is now changed to:
lto1: error: ‘-fcf-protection=full’ is not supported for this target
mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-9 returned 1 exit status
compilation terminated.
lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/9//accel/nvptx-none/mkoffload returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
I got one step further with:
gcc-10 -O2 -ffast-math -fopenacc -fopt-info-all-omp -fcf-protection=none -foffload=nvptx laplace2dkernels.c
but just to find the next problem:
gcc-10: fatal error: GCC is not configured to support nvptx as offload target
compilation terminated
So it seems they only compiled it for AMD GCN.
If you use
gcc-10 -O2 -ffast-math -fopenacc -fopt-info-all-omp -fcf-protection=none -foffload=nvptx-none laplace2dkernels.c
>laplace2dkernels.c:74:9: optimized: assigned OpenACC seq loop parallelism
>/usr/bin/ld: /tmp/ccYd0cZe.crtoffloadtable.o: warning: relocation against >`__offload_vars_end' in read-only section `.rodata'
It compiles but then when running it misses:
libgomp: while loading libgomp-plugin-gcn.so.1: libgomp-plugin-gcn.so.1: cannot open shared object file: No such file or directory
I do not need to install those libraries because I want to get it to run with my Nvidia card.
With the PGI compilers everything worked fine.
NOTE: I am also using WSL and special NVIDIA drivers to allow for GPU passthrough.
Here's what worked for me for a Tiny C++ stencil code with OpenACC directives, after installing gcc-10-offload-nvptx:
g++ -c -g -O -fopenacc -foffload=nvptx-none -fcf-protection=none -foffload=-misa=sm_35 -fno-stack-protector stencil_acc.cxx
g++ -o stencil_acc -g -O -fopenacc -foffload=nvptx-none -fcf-protection=none -foffload=-misa=sm_35 -fno-stack-protector util.o stencil_acc.o

Issue with Intel compilation on macOS 10.15 Catalina : catastrophic error: cannot open source file "stdlib.h"

I try desperatly to compile with c++ intel compiler (icpc) a simple code that I was used to compile on my previous macBook 10.14.
Now, since Headers don't exist anymore with 10.15 Catalina, the compiler has difficulties to find stdlib.h. Here the output I get :
icpc -std=c++11 -O3 -xHost -fp-model strict -prec-div -prec-sqrt -fma -ftz -mp1 -qopenmp -Wall -c -I/opt/intel/compilers_and_libraries_2020.2.258/mac/mkl/include -mkl=parallel main.cpp -o main.o
In file included from /Library/Developer/CommandLineTools/usr/include/c++/v1/math.h(301),
from /opt/intel/compilers_and_libraries_2020.2.258/mac/compiler/include/math.h(177),
from /Library/Developer/CommandLineTools/usr/include/c++/v1/cmath(304),
from TSAF.h(1),
from main.cpp(1):
/Library/Developer/CommandLineTools/usr/include/c++/v1/stdlib.h(20): catastrophic error: cannot open source file "stdlib.h"
#include_next <stdlib.h>
^
compilation aborted for main.cpp (code 4)
make: *** [Makefile:13: main.o] Error 4
./main_intel.exe: No such file or directory
I tried a lot of potential workarounds from the net but none works. I would like to avoid to create a directory /usr/include/ by removing the security system of my macBook.
I thought maybe this would work by downloading XCode_12.0.1 but same problems remain.
For the moment, I have the version Catalina OS 10.15.7, all has been updated.
EDIT 1: There is something that I don't understand : on my previous macBook 10.14, I didn't need to use the headers of clang c++ for intel compilation.
If anyone could give me a suggestion/clue/track, this would be fine.
Run the command in the Terminal
sudo xcode-select --reset
And then check if proper developer tools are selected instead of the command line tools
xcode-select -p

Debug symbols not included in gcc-compiled C++

I am building a module in C++ to be used in Python. My flow is three steps: I compile the individual C++ sources into objects, create a library, and then run a setup.py script to compile the .pyx->.cpp->.so, while referring to the library I just created.
I know I can just do everything in one step with the Cython setup.py, and that is what I used to do. The reason for splitting it into multiple steps is I'd like the C++ code to evolve on its own, in which case I would just use the compiled library in Cython/python.
So this flow works fine, when there are no bugs. The issue is I am trying to find the source of a segfault, so I'd like to get the debugging symbols so that I can run with gdb (which I installed on OSX 10.14, it was a pain but it worked).
I have a makefile, which does the following.
Step 1: Compile individual C++ source files
All the files are compiled with the bare minimum flags, but -g is there:
gcc -mmacosx-version-min=10.7 -stdlib=libc++ -std=c++14 -c -g -O0 -I ./csrc -o /Users/colinww/system-model/build/data_buffer.o csrc/data_buffer.cpp
I think even here there is a problem: when I do nm -pa data_buffer.o, I see no debug symbols. Furthermore, I get:
(base) cmac-2:system-model colinww$ dsymutil build/data_buffer.o
warning: no debug symbols in executable (-arch x86_64)
Step 2: Compile cython sources
The makefile has the line
cd $(CSRC_DIR) && CC=$(CC) CXX=$(CXX) python3 setup_csrc.py build_ext --build-lib $(BUILD)
The relevant parts of setup.py are
....
....
....
compile_args = ['-stdlib=libc++', '-std=c++14', '-O0', '-g']
link_args = ['-stdlib=libc++', '-g']
....
....
....
Extension("circbuf",
["circbuf.pyx"],
language="c++",
libraries=["cpysim"],
include_dirs = ['../build'],
library_dirs=['../build'],
extra_compile_args=compile_args,
extra_link_args=link_args),
....
....
....
ext = cythonize(extensions,
gdb_debug=True,
compiler_directives={'language_level': '3'})
setup(ext_modules=ext,
cmdclass={'build_ext': build_ext},
include_dirs=[np.get_include()])
When this is run, it generates a bunch of compilation/linking commands like
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/colinww/anaconda3/include -arch x86_64 -I/Users/colinww/anaconda3/include -arch x86_64 -I. -I../build -I/Users/colinww/anaconda3/lib/python3.7/site-packages/numpy/core/include -I/Users/colinww/anaconda3/include/python3.7m -c circbuf.cpp -o build/temp.macosx-10.7-x86_64-3.7/circbuf.o -stdlib=libc++ -std=c++14 -O0 -g
and
g++ -bundle -undefined dynamic_lookup -L/Users/colinww/anaconda3/lib -arch x86_64 -L/Users/colinww/anaconda3/lib -arch x86_64 -arch x86_64 build/temp.macosx-10.7-x86_64-3.7/circbuf.o -L../build -lcpysim -o /Users/colinww/system-model/build/circbuf.cpython-37m-darwin.so -stdlib=libc++ -g
In both commands, the -g flag is present.
Step 3: Run debugger
Finally, I run my program with gdb
(base) cmac-2:sim colinww$ gdb python3
(gdb) run system_sim.py
It dumps out a ton of stuff related to system files (seems unrelated) and finally runs my program, and when it segfaults:
Thread 2 received signal SIGSEGV, Segmentation fault.
0x0000000a4585469e in cpysim::DataBuffer<double>::Write(long, long, double) () from /Users/colinww/system-model/build/circbuf.cpython-37m-darwin.so
(gdb) info local
No symbol table info available.
(gdb) where
#0 0x0000000a4585469e in cpysim::DataBuffer<double>::Write(long, long, double) () from /Users/colinww/system-model/build/circbuf.cpython-37m-darwin.so
#1 0x0000000a458d6276 in cpysim::ChannelFilter::Filter(long, long, long) () from /Users/colinww/system-model/build/chfilt.cpython-37m-darwin.so
#2 0x0000000a458b0d29 in __pyx_pf_6chfilt_6ChFilt_4filter(__pyx_obj_6chfilt_ChFilt*, long, long, long) () from /Users/colinww/system-model/build/chfilt.cpython-37m-darwin.so
#3 0x0000000a458b0144 in __pyx_pw_6chfilt_6ChFilt_5filter(_object*, _object*, _object*) () from /Users/colinww/system-model/build/chfilt.cpython-37m-darwin.so
#4 0x000000010002f1b8 in _PyMethodDef_RawFastCallKeywords ()
#5 0x000000010003be64 in _PyMethodDescr_FastCallKeywords ()
As I mentioned above, I think the problem starts in the initial compilation step. This has nothing to do with cython, I'm just calling gcc from the command line, passing the -g flag.
(base) cmac-2:system-model colinww$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Any help is appreciated, thank you!
UPDATE
I removed the gcc tag and changed it to clang. So I guess now I'm confused, if Apple will alias gcc to clang, doesn't that imply that in "that mode" it should behave like gcc (and, implied, someone made sure it was so).
UPDATE 2
So, I never could get the debug symbols to appear in the debugger, and had to resort to lots of interesting if-printf statements, but the problem was due to an index variable becoming undefined. So thanks for all the suggestions, but the problem is more or less resolved (until next time). Thanks!
The macOS linker doesn't link debug information into the final binary the way linkers usually do on other Unixen. Rather it leaves the debug information in the .o files and writes a "debug map" into the binary that tells the debugger how to find and link up the debug info read from the .o files. The debug map is stripped when you strip your binary.
So you have to make sure that you don't move or delete your .o files after the final link, and that you don't strip the binary you are debugging before debugging it.
You can check for the presence of the debug map by doing:
$ nm -ap <PATH_TO_BINARY> | grep OSO
You should see output like:
000000005d152f51 - 03 0001 OSO /Path/To/Build/Folder/SomeFile.o
If you don't see that the executable probably got stripped. If the .o file is no around then somebody cleaned your build folder earlier than they should have.
I also don't know if gdb knows how to read the debug map on macOS. If the debug map entries and the .o files are present, you might try lldb and see if that can find the debug info. If it can, then this is likely a gdb-on-macOS problem. If the OSO's and the .o files are all present, then something I can't guess went wrong, and it might be worth filing a bug with http://bugreporter.apple.com.

Compiling Yap on windows 8

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.

failed to exec /Applications/Xcode.app/Contents/Developer/usr/bin/clang: No such file or directory

Xcode 5 breaks my compilation script. I suspect because clang is now located directly in /usr/bin instead of its usual location. However, I'm not sure how I can tell this to gcc. Any tips would be much appreciated. I am compiling for iOS.
CPPFLAGS= -arch i686 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -fno-short-wchar -fno-short-enums -miphoneos-version-min=4.2.1
CXXFLAGS= -arch i686 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -fno-short-wchar -fno-short-enums -miphoneos-version-min=4.2.1
CFLAGS=
gcc -Iinclude -arch i686 --sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -fno-short-wchar -fno-short-enums -miphoneos-version-min=4.2.1 -c -o src_c/stem_UTF_8_danish.o src_c/stem_UTF_8_danish.c
gcc: failed to exec /Applications/Xcode.app/Contents/Developer/usr/bin/clang: No such file or directory
make: *** [src_c/stem_UTF_8_danish.o] Error 71
Update. I was able to repeat the problem by directly calling gcc from the iPhoneSimulator usr/bin with no arguments.
tim$ /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform//Developer/us r/bin/gcc
gcc: failed to exec /Applications/Xcode.app/Contents/Developer/usr/bin/clang: No such file or directory
I was able to get it to compile by using clang from /usr/bin with the appropriate sysroot. but is this equivalent?
I noticed the same problem when I upgraded to Xcode 5.1 When I ran "xcrun -find clang", it said "You have not agreed to the XCode license agreements. You must agree to both Xcode license agreements below in order to use Xcode." It spewed out the agreements and gave me an opportunity to agree, which I did. And that fixed the problem. Go figure.
Cheers - Ed