I am attempting to build and run the example code from the NVlabs project SASSI which can be used to instrument CUDA code. However, I am struggling to get even the included sample Makefile and matrixMul.cu to build and run properly.
I have tried adding the --maxrregcount=16 and -rcd=true nvcc flags, but I think my real issue is with linking properly to the SASSI libraries. All of the library paths listed in the nvcc output below resolve to actual directories with .so files.
Any tips or debugging steps are much appreciated.
$ make clean
rm -f -f matrixMul *.o
$ make branch
/usr/local/sassi7//bin/nvcc -I./inc -c -gencode
arch=compute_35,code=sm_35 -gencode arch=compute_50,code=sm_50
-Xlinker "--wrap=main" -Xlinker "--wrap=exit" -lineinfo -Xptxas --sassi-inst-before="cond-branches" -Xptxas --sassi-before-args="cond-branch-info" -g -O3 -dc -o matrixMul.o matrixMul.cu
*
* SASSI Instrumentation Details
*
* For the settings you passed in, you'll need to make sure that you have
* an instrumentation library with the following properties:
* - It MUST BE compiled using only 16 registers!! To accomplish this
* simply compile your library with the nvcc flag, --maxrregcount=16
* - It must define the following functions:
* device void sassi_before_handler(SASSIBeforeParams*,SASSICondBranchParams*)
*
*
* SASSI Instrumentation Details
*
* For the settings you passed in, you'll need to make sure that you have
* an instrumentation library with the following properties:
* - It MUST BE compiled using only 16 registers!! To accomplish this
* simply compile your library with the nvcc flag, --maxrregcount=16
* - It must define the following functions:
* device void sassi_before_handler(SASSIBeforeParams*,SASSICondBranchParams*)
*
****************************************************************************** /usr/local/sassi7//bin/nvcc -o matrixMul matrixMul.o -gencode
arch=compute_35,code=sm_35 -gencode arch=compute_50,code=sm_50
-Xlinker "--wrap=main" -Xlinker "--wrap=exit" -L../instlibs/lib -lbranch -L/usr/local/sassi7//extras/CUPTI/lib64 -lcupti -lcudadevrt -Xlinker -rpath,/usr/local/sassi7//extras/CUPTI/lib64 -L/lib -lboost_regex -lcrypto -Xlinker -rpath,/lib nvlink error : Undefined reference to
'_Z20sassi_before_handlerP17SASSIBeforeParamsP21SASSICondBranchParams'
in 'matrixMul.o' make: * [matrixMul] Error 255**
The solution was to install Boost, set the appropriate paths in instlibs/env.mk and run make all from instlibs/ before trying to build the example code. The paths were set correctly, but not all of the required SASSI libraries had been generated.
Related
I have a pretty simple CMake-based project that builds one lib and a small executable that uses it. It builds fine on Linux with GCC, but fails on Mac OS with loads of errors of the following kind. The inciting line of code in main.cpp is the second one here:
#include <cstdlib>
#include <memory>
The first of many similar errors:
[build] In file included from /Users/me/data/series2server/main.cpp:2:
[build] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/memory:671:
[build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__algorithm/search.h:34:19: error: no member named 'make_pair' in namespace 'std::__1'
[build] return _VSTD::make_pair(__first1, __first1); // Everything matches an empty sequence
This appears to be a mismatch between Clang and GCC uses of std. But I can't figure out why CMake is configuring things to call clang++ but putting "std=gnu++14" in the compiler invocation. I did a full-text search for "std=gnu" in the whole source tree and didn't find it. I do see this in various CMakeLists.txt files:
set( CMAKE_CXX_STANDARD 14 )
A compiler invocation is below. Where might I look for where this gnu option is specified? Thanks!
[build] cd /Users/me/data/series2server/build/restbed && /usr/bin/clang++ -DBUILD_SSL -I/Users/me/data/series2server/restbed/source -isystem /Users/me/data/series2server/restbed/dependency/asio/asio/include -isystem /Users/me/data/series2server/restbed/dependency/openssl/include -Wall -Wextra -Weffc++ -pedantic -Wno-unknown-pragmas -Wno-deprecated-declarations -Wno-non-virtual-dtor -DASIO_STANDALONE=YES -Wno-deprecated-declarations -g -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -std=gnu++14 -MD -MT restbed/CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o -MF CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o.d -o CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o -c /Users/me/data/series2server/restbed/source/corvusoft/restbed/detail/service_impl.cpp
From n.m.'s comment 10 years ago, for clarity:
set( CMAKE_CXX_STANDARD 14 ) sets gcc or clang flag to -std=gnu++14, unless CXX_EXTENSIONS property (or CMAKE_CXX_EXTENSIONS variable) is set to OFF.
I am trying to cross compile my application for a arm based system.
I have 2 libraries compiled in the following way:
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libfoo.so foo.o
$ gcc -shared --sysroot=$DIR_PATH -o $LIBPATH/libbar.so bar.o
A third library is compiled:
gcc -shared -o $LIBPATH/libfoobar.so --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH foobar.o -lfoo -lbar
Then finally I compile a binary:
gcc -o app --sysroot=$DIR_PATH -L$LIBPATH -Wl,rpath=$RUN_TIME_PATH app.o -lfoobar
However when compiling app I get
warning: libfoo.so, needed by libfoobar.so, not found (try using -rpath or -rpath-link)
I believe you need to use -Wl,-rpath-link=$LIBPATH to tell the linker where to look to resolve runtime library references during the link operation.
More info can be found in the ld documentation: https://sourceware.org/binutils/docs-2.37/ld/Options.html
When I try to compile a trivial example test.c
int main () {
return 0;
}
for a cortex m7 target with hard float ABI by using the following invocation
arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs test.c
I get this error:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o: Conflicting CPU architectures 13/1
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/crt0.o
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: error: a.out uses VFP register arguments, /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libc.a(lib_a-atexit.o) does not
[snip]
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: failed to merge target specific data of file /usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/lib/libnosys.a(_exit.o)
collect2: error: ld returned 1 exit status
So the issue is that gcc is linking to the wrong libc.a. If I use the argument print-multi-directory, it would appear that my version of arm-none-eabi-gcc should support this architecture:
$ arm-none-eabi-gcc -mcpu=cortex-m7 -mfpu=fpv5-d16 -mfloat-abi=hard --specs=nosys.specs --print-multi-directory
thumb/v7e-m/fpv5/hard
And I can list the different versions of libc.a that are provided by arm-none-eabi-gcc:
$ find /usr/lib/arm-none-eabi/ -name libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/fpu/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-sp-d16/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/libc.a
/usr/lib/arm-none-eabi/newlib/armv7e-m/softfp/fpv5-d16/libc.a
/usr/lib/arm-none-eabi/newlib/libc.a
/usr/lib/arm-none-eabi/newlib/armv6-m/libc.a
/usr/lib/arm-none-eabi/newlib/fpu/libc.a
/usr/lib/arm-none-eabi/newlib/thumb/libc.a
/usr/lib/arm-none-eabi/newlib/armv7-m/libc.a
So it looks like there is a version of libc.a compiled for my desired architecture, but gcc isn't linking against it. How can I get gcc to link against the correct version of libc.a?
I'm using arm-none-eabi-gcc version 6.3.1 provided by the gcc-arm-none-eabi package for Ubuntu 18.04.
When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
I would like to generate my android native application with the android NDK and Cmake, so, I've downloaded the android-cmake toolchain.
Cmake generate my project successfully, but when I try to go in the generate directory and try to run "make", I've got the following error:
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/ldz/Desktop/myProject
[ 1%] Building CXX object Project/src/Main/Core/CMakeFiles/Core.dir/Main/Main.cpp.o
arm-linux-androideabi-g++: error: unrecognized command line option '-stdlib=libc++'
I don't know what is wrong here, my project use C++11, here is my g++ --version result:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
Thanks!
To build an Android NDK project with Cmake and create APK, you should do :
Instead of using android-cmake, you should use the fork from taka-no-me.
Then use Apk.cmake from pixellight. Copy also [AndroidManifest.xml.in, LoadLibraries.java.in, strings.xml.in] from this repo.
Have a CMakeLists.txt like this :
cmake_minimum_required(VERSION 2.8.3)
project(testBuilder)
include("Apk.cmake" REQUIRED)
include_directories(${ANDROID_NDK}/sources/android/native_app_glue)
set(TEST_SRC
${ANDROID_NDK}/sources/android/native_app_glue/android_native_app_glue.c
src/Main.cpp
)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -ffor-scope -fno-rtti -fno-exceptions -pipe -ffunction-sections -fdata-sections -ffast-math -Wnon-virtual-dtor -Wreorder -Wsign-promo -fvisibility=hidden -fvisibility-inlines-hidden -Wstrict-null-sentinel -Os -funroll-all-loops -fpeel-loops -ftree-vectorize")
set(LINKER_FLAGS "${LINKER_FLAGS} -Wl,--as-needed -Wl,--gc-sections -Wl,--no-undefined -Wl,--strip-all -Wl,-rpath-link=${ANDROID_NDK_SYSROOT}/usr/lib/ -L${ANDROID_NDK_SYSROOT}/usr/lib/")
add_library(test SHARED ${TEST_SRC})
target_link_libraries(test log android)
set_target_properties(test PROPERTIES COMPILE_DEFINITIONS "ANDROID")
set(APP_SHARED_LIBRARIES ${LIBRARY_OUTPUT_PATH}/libtest.so)
android_create_apk(test "${CMAKE_BINARY_DIR}/apk" "${APP_SHARED_LIBRARIES}" "" "Data")
This is Main.cpp
#include <android_native_app_glue.h>
#include <android/log.h>
#define APPNAME "TestApp"
void android_main(struct android_app* state)
{
app_dummy(); // Make sure glue isn't stripped
__android_log_print(ANDROID_LOG_INFO, APPNAME, "HolyShit you did it !");
ANativeActivity_finish(state->activity);
}
Based on Vi.:s answer I did a clone of android-cmake on github and added a modified Apk.cmake called android.apk.cmake. I use NativeActivity instead of pixellight:s LoadLibraries.java.
The clone is here:
https://github.com/Discordia/android-cmake
I created the example in Vi.:s answer:
https://github.com/Discordia/android-cmake-example