My problem is related to the one discussed here:
Is there a way that OpenMP can operate on Qt spanwed threads?
Upon trying to run my Qt-based program under Mac OS that has an OpenMP clause in a secondary thread, it crashed. After browsing through the web, now I understand that it is caused by a bug in the rather old version (4.2) of gcc supplied by Apple.
Then I downloaded the latest 4.6 version of gcc from http://hpc.sourceforge.net and tried to compile the project, but I got the following errors from g++ compiler:
unrecognized option ‘-arch’
unrecognized option ‘-Xarch_x86_64’
I learned that this is because these are options, which can be only interpreted by the custom-configured Apple-gcc compiler, but not by standard gcc.
Could anybody please help me could I overcome this issue and configure g++ 4.6 to use with Qt in order to get a bug-free OpenMP support? I admit that I'm a newbie under Mac OS platform with regard to compilers and programming and would like to port my code from Visual Studio-Qt environment.
Many thanks in advance!
If you aren't afraid of messing with your Qt installation, then change the QMAKE_CFLAGS_X86_64 entry in ~/QtSDK/Desktop/Qt/4.8.1/gcc/mkspecs/common/g++-macx.conf.
Replace ‘-Xarch_x86_64’ with ‘-arch x86_64’.
You can use your non-Apple gcc v4.6 and compile a binary for each architecture you want to build (use --target=${ARCH} should be fine for i386 and x86_64). Then once you have a binary for each of the architectures use lipo like so:
lipo -create -arch i386 binary_32bit -arch x86_64 binary_64bit -output binary_universal
This will create a fat binary (aka universal binary) named binary_universal from binary_32bit and binary_64bit.
Or you could use clang/llvm instead of gcc, which probably won't have the bug you described and (if supplied via Apple's developer tools) should be able to compile universal binaries directly.
You should run qmake woth corresponding -spec option, for example, to use gcc46 on freebsd it is needed to run qmake so:
qmake --spec=freebsd-g++46
Lipo can indeed be used to put multiple object files together into a "fat" object file, in fact it turns out this is just what apple's compiler does. Their GCC compiler is actually a driver that maps various architectures to the appropriate compiler for the architecture and then mashes the objects together using lipo.
see: http://lists.macosforge.org/pipermail/macports-dev/2011-September/016210.html
Here is the source file for that driver:
http://opensource.apple.com/source/gcc/gcc-5666.3/driverdriver.c
All one needs to do to get a new version of GCC to honor the -arch flag is to modify this driver and get it to point to a script wrapper for your version of gcc that adds the appropriate flags for the given architecture and then passes all the rest of the arguments. Something like this:
#!/bin/sh
/opt/local/bin/gcc-mp-4.6 -m32 $#
and
#!/bin/sh
/opt/local/bin/gcc-mp-4.6 -m64 $#
Here is a link that talks about how to do it, and provides a cmake project to easily get the macports version of GCC fixed up and supporting the -arch flag for the two intel architectures:
http://thecoderslife.blogspot.com/2015/07/building-with-gcc-46-and-xcode-4.html
Related
I have a c++ program, which contains two classes. one of them is using libssh and some of its functions and another one is for calculating cpu usage. there is a link of how I a built and added libssh:libssh's functions couldn't be found on qt my program works fine. now I want to build a .so library out of it to use in other programs. first I made two .o file like this:
gcc -c -fPIC info.cpp -o info.o
gcc -c -fPIC cpuusage.cpp -o cpuusage.o
and I made a .so from them:
gcc -shared -o libsmc.so info.o cpuusage.o
whenever I want to use libsmc.so, I include info.h, but the problem is that libssh functions cannot be found. I think I have to add libssh statically to my project. but I don't know how to!
Ps:I read this explanation :Using a shared library in another shared library , but this is for linking shared libraries that have been used in a program via command line, I don't wanna compile program with command line and want to link libraries constantly.
To build a C/C++ software using external libraries, I would really recommend to use a build system instead of typing commands manually.
The most used build system for C++ is CMake (https://cmake.org/), which is well supported by Qt, but there are many other build systems existing. Another is QMake, which is Qt's build system.
If you are using an IDE, like QtCreator or Microsoft Visual Studio, CMake is integrated as well. There are plenty of tutorials and example to use CMake for a project (e.g. https://mirkokiefer.com/cmake-by-example-f95eb47d45b1), even though the learning curve is not as steep as I would want.
But if you still want to use command line (or to debug the command line generated by CMake): When linking against a library, you need to:
Give the include path to the compiler, i.e. the path where the .h of the external library can be found. With gcc, this is done with -I, e.g. "-I/usr/lib/mylib/include".
Give the library folder and name to the linker, i.e. the path where to find the compiled library, as well as its name. With gcc, this is done with -L for the path and -l for the name. Check the gcc manual for more details about these commands.
And if you want to use CMake, then you can use the functions:
target_include_directories(..)
and
target_link_libraries(..)
still facing some strange compilation error while using MSYS2 mingw64 to compile OpenLDAP
I think it boils down to some win socket thing, currently facing 2 major errors during make depend and make
during make depend
cannot locate nt_err.c in servers/slapd/slapi ==> I resorted to copy nt_err.c from libraries/liblber/nt_err.c
Then came the fatal error while make depend in slapi. Command used by make depend: make -w -I/usr/include -I/usr/include -I/usr/include -I/usr/include depend, it maybe because I have passed -I/usr/include in the main make depend
but still
Entering directory '/home/Jimmy/openldapsrc/openldap-2.4.46/servers/slapd/slapi'
../../../build/mkdep -l -d "." -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../include -I./.. -I. plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c nt_err.c
In file included from slapi_utils.c:34:0:
../../../include/netdb.h:73:10: fatal error: netinet/in.h: No such file or directory
#include <netinet/in.h>
^~~~~~~~~~~~~~
compilation terminated.
And actually I have seen a lot of similar errors, for example during make it will also give error in slapi like
No such file or directory
#include <sys/socket.h>
^~~~~~~~~~~~~~
compilation terminated.
I have checked with pacman -Fs in.h socket.h the output are as follow
msys/msys2-runtime-devel 2.10.0-2
usr/include/cygwin/in.h
usr/include/netinet/in.h
usr/include/sys/socket.h
and I have msys2-runtime-devel installed. Nonetheless this reminded me that during ./configure output contained
checking sys/socket.h usability... no
checking sys/socket.h presence... no
so Ｉ tried to run gcc -xc -E -v - trying to determine what directory is included, however in MSYS2-MINGW64 it stopped at this
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.3.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --enable-libstdcxx-filesystem-ts=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.3.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/cc1.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/ -D_REENTRANT - -mtune=generic -march=x86-64
the cc1 gave no output, froze MSYS2 and I have to terminate cc1 from task manager.
Then I run directly C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/cc1.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/ -D_REENTRANT - -mtune=generic -march=x86-64
it returned
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.3.0/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64- w64-mingw32/7.3.0/include-fixed"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include"
#include "..." search starts here:
#include <...> search starts here:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64- mingw32/7.3.0/../../../../include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/include-fixed
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/include
End of search list.
Turns out the #include <...> search does not include the /usr/include directory of MSYS2, should have been C:/msys64/mingw64/bin/../../usr/include
I tried putting ENV CFLAGS="-I/usr/include" before ./configure, that caused more errors, many .h not usable but presence. and sys/socket.h is usable and presence.
So turns out -I/usr/include somehow did not pass into the compiler?
My Question is, is this configurable? Or is there something wrong with my setup?
OpenLDAP 2.4.46
MSYS2 20161025
MSYS2 has three different toolchains with different purposes:
The msys-2.0.dll-based toolchain, which creates executables that use the POSIX emulation capabilities provided by msys-2.0.dll. The main compiler is /usr/bin/gcc and it uses headers from /usr/include. This is the toolchain to use if your program was written for a Linux or another POSIX-type operating system and you are finding it difficult to port it to Windows because it uses a lot of features not supported by Microsoft.
MinGW 32-bit toolchain. This compiles native Windows software that can run on 32-bit or 64-bit versions of Windows. The main compiler is /mingw32/bin/gcc. To use this toolchain you must launch MSYS2 with the "MinGW-w64 32-bit Shell" shortcut or launch mingw32.exe. This toolchain is not compatible with the headers in /usr/include, but it can use native Windows headers with interfaces defined by Microsoft, like windows.h.
MinGW 64-bit toolchain. This toolchain is just like the 32-bit toolchain except the executables are 64-bit executables, and thus only work on 64-bit Windows. It has its own shortcut in the start menu, and can also be launched with mingw64.exe.
I don't know anything about OpenLDAP, but if it is requiring a bunch of headers that the MinGW toolchains don't have, you could either try to port it to Windows or switch over to building it with the msys-2.0.dll-based toolchain.
This question is related to LLVM/clang.
I already know how to compile opencl-kernel-file(.cl) using OpenCL API ( clBuildProgram() and clGetProgramBuildInfo() )
my question is this:
How to compile opencl-kernel-file(.cl) to LLVM IR with OpenCL 1.2 or higher?
In the other words, How to compile opnecl-kernel-file(.cl) to LLVM IR without libclc?
I have tried various methods to get LLVM-IR of OpenCL-Kernel-File.
I first followed the clang user manual.(https://clang.llvm.org/docs/UsersManual.html#opencl-features) but it did not run.
Secondly, I found a way to use libclc.
commands is this:
clang++ -emit-llvm -c -target -nvptx64-nvidial-nvcl -Dcl_clang_storage_class_specifiers -include /usr/local/include/clc/clc.h -fpack-struct=64 -o "$#".bc "$#" <br>
llvm-link "$#".bc /usr/local/lib/clc/nvptx64--nvidiacl.bc -o "$#".linked.bc <br>
llc -mcpu=sm_52 -march=nvptx64 "$#".linked.bc -o "$#".nvptx.s<br>
This method worked fine, but since libclc was built on top of the OpenCL 1.1 specification, it could not be used with OpenCL 1.2 or later code such as code using printf.
And this method uses libclc, which implements OpenCL built-in functions in the shape of new function. You can observe that in the assembly(ptx) of result opencl binary, it goes straight to the function call instead of converting it to an inline assembly. I am concerned that this will affect gpu behavior and performance, such as execution time.
So now I am looking for a way to replace compilation using libclc.
As a last resort, I'm considering using libclc with the NVPTX backend and AMDGPU backend of LLVM.
But if there is already another way, I want to use it.
(I expect that the OpenCL front-end I have not found yet exists in clang)
My program's scenarios are:
There is opencl kernel source file(.cl)
Compile the file to LLVM IR
IR-Level process to the IR
Compile(using llc) the IR to Binary
with each gpu targets(nvptx, amdgcn..)
Using the binary, Run host(.c or .cpp with lib OpenCL) with clCreateProgramWithBinary()
Now, When I compile kernel source file to LLVM IR, I have to include header of libclc(-include option in first one of above command) for compiling built-in functions. And I have to link libclc libraries before compile IR to binary
My environments are below:
GTX960
- NVIDIA's Binary appears in nvptx format
- I'm using sm_52 nvptx for my gpu.
Ubuntu Linux 16.04 LTS
LLVM/Clang 5.0.0
- If there is another way, I am willing to change the LLVM version.
Thanks in advice!
Clang 9 (and up) can compile OpenCL kernels written in the OpenCL C language. You can tell Clang to emit LLVM-IR by passing the -emit-llvm flag (add -S to output the IR in text rather than in bytecode format), and specify which version of the OpenCL standard using e.g. -cl-std=CL2.0. Clang currently supports up to OpenCL 2.0.
By default, Clang will not add the standard OpenCL headers, so if your kernel uses any of the OpenCL built-in functions you may see an error like the following:
clang-9 -c -x cl -emit-llvm -S -cl-std=CL2.0 my_kernel.cl -o my_kernel.ll
my_kernel.cl:17:12: error: implicit declaration of function 'get_global_id' is invalid in OpenCL
int i = get_global_id(0);
^
1 error generated.
You can tell Clang to include the standard OpenCL headers by passing the -finclude-default-header flag to the Clang frontend, e.g.
clang-9 -c -x cl -emit-llvm -S -cl-std=CL2.0 -Xclang -finclude-default-header my_kernel.cl -o my_kernel.ll
(I expect that the OpenCL front-end I have not found yet exists in clang)
There is an OpenCL front-end in clang - and you're using it, otherwise you couldn't compile a single line of OpenCL with clang. Frontend is Clang recognizing the OpenCL language. There is no OpenCL backend of any kind in LLVM, it's not the job of LLVM; it's the job of various OpenCL implementations to provide proper libraries. Clang+LLVM just recognizes the language and compiles it to bitcode & machine binaries, that's all it does.
in the assembly(ptx) of result opencl binary, it goes straight to the function call instead of converting it to an inline assembly.
You could try linking to a different library instead of libclc, if you find one. Perhaps NVidia's CUDA has some bitcode libraries somewhere, then again licensing issues... BTW are you 100% sure you need LLVM IR ? getting OpenCL binaries using the OpenCL runtime, or using SPIR-V, might get you faster binaries & certainly be less painful to work with. Even if you manage to get a nice LLVM IR, you'll need some runtime which actually accepts it (i could be wrong, but i doubt proprietary AMD/NVIDIA OpenCL will just accept random LLVM IR as inputs).
Clang does not provide a standard CL declaration header file (for example, C's stdio.h), which is why you're getting "undefined type float" and whatnot.
If you get one such header, you can then mark it as implicit include using "clang -include cl.h -x cl [your filename here]"
One such declaration header can be retrieved from the reference OpenCL compiler implementation at
https://github.com/KhronosGroup/SPIR-Tools/blob/master/headers/opencl_spir.h
And by the way, consider using this compiler which generates SPIR (albeit 1.0) which can be fed into OpenCL drivers as input.
I am using qmake to cross-compile my ARM based program on Ubuntu. I have ran into the multithreading issue as described in this thread:
C++ 11 Threads, Error Pure virtual function called
One answer suggests adding the flag to the compilation as:
g++ -pthread -std=c++11 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} thread1.cpp
I am not sure how to add this -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4} in my qmake project file.
I did QMAKE_CXXFLAGS += -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1,2,4}. My error still remains so I wanted to confirm if this is the right way to add that flag.
It's a bash glob/wildcard. Expands to
-D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 -D__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
Using glew, I'm trying to link the simple program
#include </usr/include/GL/glew.h>
int main (int argc, const char * argv[])
{
glewInit();
return 0;
}
in XCode 4, under OSX Lion, which reports the error:
ld: library not found for -lGLEW.1.7.0
Command /Developer/usr/bin/clang++ failed with exit code 1
however, the error output also reports the following flags for the linker
-mmacosx-version-min=10.7 -L/usr/lib -lGLEW.1.7.0 -lglfw -framework OpenGL -framework Cocoa
and indeed, libGLEW.1.7.0 does reside in /usr/lib
Moreover, if I try to build the program by hand, with
gcc -L/usr/lib -lGLEW.1.7.0 main.cpp
I get an a.out file without any errors reported (which if run causes a segmentation fault, but maybe that's to be expected)
Any ideas on what might be causing XCode to produce this error and how it could be avoided?
Built and installed GLEW myself and had the same issue with plain gcc inside a makefile on OS X with compilation of code from https://github.com/jckarter/hello-gl
The following steps resolved the issue:
I found my GLEW libs (libGLEW.a and libGLEW.dylib) installed in /usr/lib directory (it definitely was there owned by root with r permissions for others). Tried to change GLEW_LIB variable from the makefile to /usr/lib but still got ld: library not found for -lGLEW
after that I tried to link compiled program against static library directly (without -l flag) - for that I removed -lGLEW from gcc command and changed it to direct link t library /usr/lib/libGLEW.a - it compiled and linked fine
Ok - it's a work around to try first
Then I created two links to my libraries with the following commands:
ln -s /usr/lib/libGLEW.a /usr/local/lib/libGLEW.a
ln -s /usr/lib/libGLEW.dylib /usr/local/lib/libGLEW.dylib
and finally got it working with original makefile (only changed GLEW_LIB variable to /usr/local/lib).
Probably GLEW's make install should place libraries to /usr/local/lib directly.
(I have removed this from an edit to the question and posted it as an answer, as per leppie's suggestion)
I might have found the answer in some details I had considered unimportant in my original post. So here goes, in case others might encounter a similar problem.
Apparently, XCode4 projects use clang++ by default, which in the link phase accepts a parameter -isysroot (which apparently ld does not accept).
Now, if in your build settings (as was my case) your Base SDK has been defined as something other than Current Mac OS, the parameter -isysroot will be introduced with the value of a directory pointing to that SDK, thus (this is my guess) prepending this to all other lib directories you might be including with -L.
In my case, -L/usr/lib was effectively turning into -L/Developer/SDKs/MacOSX10.7.sdk/usr/lib which does exist and did not contain libGLEW, hence the error "library not found"