I am trying to compile the Boost 1.48 in CentOS 5.6. I need the files to be in this format:
boost_program_options-gcc41-mt-1_48
I am compiling with this bjam flags:
./b2 -q --toolset=gcc --layout=tagged --without-mpi install
but it still don't add the gcc prefix to the name.
How can I fix this?
For me (although I use darwin toolset instead of plain gcc) Bjam creates files with names, like:
libboost_program_options-xgcc42-mt-1_49.a
Create the site-config.jam or user-config.jam file, which defines your custom version of GCC toolset, as described in 'Configuration' section of the Boost.Build documentation.
Additionally, there is an example, which suggests, that standard GCC toolset has version names defined as numbers only, without the gcc prefix.
Boost output filenames are generated, by the tag rule in boostcpp.jam. You can check there, if the above solution would be insufficient
Related
I have been attempting to link a MACHO formatted object file on Linux, but I have failed miserably. So far, I have created the object file by running:
nasm -fmacho -o machoh.o hello.o
I have tried linking using:
clang --target=x86_64-apple-darwin machoh.o
but that failed. I have attempted using GCC, LD, and other linkers but I have still failed miserably. Are there any ideas on how I could solve my problem?
Thank you very much.
The most accessible solution would be lld, the LLVM linker.
lld does not ship with clang, but is a separate package.
sudo apt install lld
If you installed a version of clang that isn't the default (e.g. clang-12 explicitly), then you should use the same version for lld (i.e. lld-12).
Get a MacOS SDK from somewhere. This GitHub repo archives them.
If you're uncomfortable using the above, the "legitimate" way of obtaining it without a Mac would be:
Create an Apple ID
Go to https://developer.apple.com/download/all/
Download the "Command Line Tools for Xcode <version>"
Mount or extract the dmg
Extract the XAR package
For each ".pkg" folder inside, run pbzx <Payload | cpio -i
Find the Library/Developer/CommandLineTools/SDKs/MacOSX.sdk inside.
Feed both of the above to clang:
clang --target=x86_64-apple-darwin -fuse-ld=lld --sysroot=path/to/MacOSX.sdk machoh.o
I have tried linking using: clang --target=x86_64-apple-darwin machoh.o
but that failed.
Failed how? Details matter.
Anyway, there are 3 commonly used linkers on Linux: BFD-ld, Gold, and (newest) LLD.
Of these, Gold is an ELF-only linker, and will not work for Mach-O.
BFD-ld is only configured to support a few emulations (use ld --help to see which ones) in my distribution. BFD does appear to support Mach-O, so it's probably possible to build a Linux BFD-ld cross-linker with such support.
LLD should support Mach-O out of the box, but you are probably not using LLD.
So your first step should be to figure out which linker clang --target=x86_64-apple-darwin ... uses, and then make it use the one which does support Mach-O.
I am new to Cuda, and I am trying to compile this simple test_1.cu file:
#include <stdio.h>
__global__ void kernel(void)
{
}
int main (void)
{
kernel<<<1,1>>>();
printf( "Hello, World!\n");
return 0;
}
using this: nvcc test_1.cu
The output I get is:
In file included from /usr/local/cuda/bin/../include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/local/cuda/bin/../include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!
my gcc --version:
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I install a second version of gcc (4.4 -) along with 4.6 without messing everything up?
I found this old topic:
CUDA incompatible with my gcc version
the answer was:
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and
the rest of the toolchain, including cuda-gdb, won't work properly.
You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second
compiler (most distributions will allow that). There is an option to
nvcc --compiler-bindir which can be used to point to an alternative
compiler. Create a local directory and the make symbolic links to the
supported gcc version executables. Pass that local directory to nvcc
via the --compiler-bindir option, and you should be able to compile
CUDA code without effecting the rest of your system.
But I have no idea how to do it
In my case I didn't have root rights, so I couldn't fully replace the current gcc (4.7) with the older version 4.4 (which I think would be a bad alternative). Although I did have rights where CUDA was installed. My solution was to create an extra folder (e.g. /somepath/gccfornvcc/), wherever I had rights, then to create a link to an nvcc accepted compiler. I already had gcc 4.4 available (but you can install it, without removing your current version).
ln -s [path to gcc 4.4]/gcc-4.4 /somepath/gccfornvcc/gcc
Then, in the same folder where the nvcc binary lives, you should find a file called nvcc.profile . There you just need to add the following line:
compiler-bindir = /somepath/gccfornvcc
And that will make nvcc use the proper compiler. This helps keeping the system in a proper state, keeping the newest compiler, but nvcc (only nvcc) will use the old compiler version.
Doing some research online shows several methods for accomplishing this task. I just tested the method found here: http://www.vectorfabrics.com/blog/item/cuda_4.0_on_ubuntu_11.04 and it worked like a charm for me. It steps you through installing gcc 4.4 and creating scripts to run that version with nvcc. If you prefer trying the method mentioned in your post I'd recommend following that first link to install gcc4.4 and then create symbolic links as mentioned in your post. Creating symbolic links in Linux is accomplished by using the 'ln' command.
For example:
ln -s [source file/folder path] [linkpath]
This link gives a few examples of creating symbolic links on both Ubuntu and Windows: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. Hopefully that points you in the right direction.
I guess you may try the new, beta, version, that based on LLVM.
Another way to make nvcc work with non-default compiler (unlike #Sluml's answer, it allows more flexibility):
At first, just like #Slump proposed, you need to create directory ~/local/gcc-4.4/, and then create there symlinks for right versions of gcc: for i in gcc gxx; do ln -s /usr/bin/${i}-4.4 ~/local/cudagcc/${i}; done. Now when you run nvcc -ccbin ~/local/gcc-4.4/ ... nvcc will use correct versions of gcc.
Here is small CMake snippet of forcing nvcc use specific host compiler.
option (CUDA_ENFORCE_HOST_COMPILER "Force nvcc to use the same compiler used to compile .c(pp) files insted of gcc/g++" OFF)
if (${CUDA_ENFORCE_HOST_COMPILER})
set (CMAKE_GCC_TEMP_DIR "CMakeGCC")
file(MAKE_DIRECTORY ${CMAKE_GCC_TEMP_DIR})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_C_COMPILER} ${CMAKE_GCC_TEMP_DIR}/gcc)
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CXX_COMPILER} ${CMAKE_GCC_TEMP_DIR}/g++)
set(CUDA_NVCC_FLAGS -ccbin ${CMAKE_GCC_TEMP_DIR} ${CUDA_NVCC_FLAGS})
endif()
Referenceļ¼
I update my gcc from 4.4 to 4.6. Then I could not use nvcc to compile my code. Luckily, by using the method provided by the following link. I set my default gcc compiler back to gcc 4.4. Now, I could compile file using either gcc4.4 or gcc4.6. quit cool
http://ubuntuguide.net/how-to-install-and-setup-gcc-4-1g4-1-in-ubuntu-10-0410-10
I believe my question is similar to this post: Linux: cannot find lgfortran though gfortran is installed.
However, since the suggested answer does not fix my problem, there seems no other choice other than asking it again, for a desperate Linux new comer like me.
Here is the problem. I installed GNU fortran compiler 4.8.4 and can find it in terminal
$ which gfortran-4.8
/usr/bin/gfortran-4.8
and
$ locate gfortran
/usr/bin/gfortran-4.7
/usr/bin/gfortran-4.8
/usr/bin/x86_64-linux-gnu-gfortran-4.7
/usr/bin/x86_64-linux-gnu-gfortran-4.8
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.7/libgfortranbegin.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortranbegin.a
/usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
/usr/share/doc/gfortran-4.7
/usr/share/doc/gfortran-4.8
/usr/share/doc/libgfortran-4.7-dev
/usr/share/doc/libgfortran-4.8-dev
/usr/share/doc/libgfortran3
/usr/share/man/man1/gfortran-4.7.1.gz
/usr/share/man/man1/gfortran-4.8.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gfortran-4.7.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gfortran-4.8.1.gz
/var/cache/apt/archives/gfortran-4.7_4.7.3-12ubuntu1_amd64.deb
/var/cache/apt/archives/gfortran-4.8_4.8.4-2ubuntu1~14.04_amd64.deb
/var/cache/apt/archives/libgfortran-4.7-dev_4.7.3-12ubuntu1_amd64.deb
/var/cache/apt/archives/libgfortran-4.8-dev_4.8.4-2ubuntu1~14.04_amd64.deb
/var/cache/apt/archives/libgfortran3_4.8.4-2ubuntu1~14.04_amd64.deb
/var/lib/dpkg/info/gfortran-4.7.list
/var/lib/dpkg/info/gfortran-4.7.md5sums
/var/lib/dpkg/info/gfortran-4.8.list
/var/lib/dpkg/info/gfortran-4.8.md5sums
/var/lib/dpkg/info/libgfortran-4.7-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.7-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.list
/var/lib/dpkg/info/libgfortran3:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.postinst
/var/lib/dpkg/info/libgfortran3:amd64.postrm
/var/lib/dpkg/info/libgfortran3:amd64.shlibs
/var/lib/dpkg/info/libgfortran3:amd64.symbols
So gfortran seems installed, although I don't understand why 4.7 version is still there after my removing it.
In setting Global Compiler Settings of Code:Blocks, when I choose GNU Fortran Compiler, and its Toolchain Executables, I tried the installation directory as
/usr
/usr/bin
and
/usr/lib/gcc/x86_64-linux-gnu/4.8/
as suggested in the previous post, Code:Blocks tell me
could not auto-detect installation path of "GNU Fortran Compiler".....
More details of compiler configuration is here in the image (Thanks to Mike's suggestion).
And here's the full list of compilers on my computer:
List of Compliers
Your posting shows that you have both gfortran-4.7 and gfortran-4.8
installed under /usr/bin.
Having multiple GCC Fortran compilers (or multiple C or C++ compilers) is
perfectly valid and commonplace. Code::Blocks will allow you configure
as many Fortran compilers as you have got, provided you give them different
names. It's also fine if you just want to configure one of them as the
"GNU Fortran Compiler" and ignore the others.
But in any case, Code::Blocks must be able to unambiguously identify the
installed compiler that you are calling "GNU Fortran Compiler". You
have specified the Compiler's installation directory as /usr/bin
and have left the Program files compiler name as gfortran.
There is no such compiler as /usr/bin/gfortran in your system,
and there is no program called gfortran anywhere in your PATH. You
have /usr/bin/gfortran-4.7 and /usr/bin/gfortran-4.8. As you have
installed both of them, Code::Blocks assumes you want both of them. It
can't tell which one of them you want to configure as "GNU Fortran Compiler".
So:-
Set Compiler's installation directory = /usr/bin
In Program files, change all occurrences of gfortran to gfortran-4.8,
if you want "GNU Fortran Compiler" to mean gfortran-4.8.
OK out.
Default compiler name in 20.3 version was mingw32-gfortran. However, the executable name coming with installation is x86_64-w64-mingw32-gfortran. If this is written in compiler settings. It works.enter image description here
The install file codeblocks-20.03mingw-setup installs the file gfortran.exe into the C:\Program Files\CodeBlocks\MinGW\bin directory. However the Settings>Compiler>toolchainexecutables autodetect function looks for mingw32-gfortran.exe.
To fix this, in toolchainexecutables, change the filename mingw32-gfortran.exe to gfortran.exe in 3 places, then autodetect will find it.
I am new to Cuda, and I am trying to compile this simple test_1.cu file:
#include <stdio.h>
__global__ void kernel(void)
{
}
int main (void)
{
kernel<<<1,1>>>();
printf( "Hello, World!\n");
return 0;
}
using this: nvcc test_1.cu
The output I get is:
In file included from /usr/local/cuda/bin/../include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/local/cuda/bin/../include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.5 and up are not supported!
my gcc --version:
gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
How can I install a second version of gcc (4.4 -) along with 4.6 without messing everything up?
I found this old topic:
CUDA incompatible with my gcc version
the answer was:
gcc 4.5 and 4.6 are not supported with CUDA - code won't compile and
the rest of the toolchain, including cuda-gdb, won't work properly.
You cannot use them, and the restriction is non-negotiable.
Your only solution is to install a gcc 4.4 version as a second
compiler (most distributions will allow that). There is an option to
nvcc --compiler-bindir which can be used to point to an alternative
compiler. Create a local directory and the make symbolic links to the
supported gcc version executables. Pass that local directory to nvcc
via the --compiler-bindir option, and you should be able to compile
CUDA code without effecting the rest of your system.
But I have no idea how to do it
In my case I didn't have root rights, so I couldn't fully replace the current gcc (4.7) with the older version 4.4 (which I think would be a bad alternative). Although I did have rights where CUDA was installed. My solution was to create an extra folder (e.g. /somepath/gccfornvcc/), wherever I had rights, then to create a link to an nvcc accepted compiler. I already had gcc 4.4 available (but you can install it, without removing your current version).
ln -s [path to gcc 4.4]/gcc-4.4 /somepath/gccfornvcc/gcc
Then, in the same folder where the nvcc binary lives, you should find a file called nvcc.profile . There you just need to add the following line:
compiler-bindir = /somepath/gccfornvcc
And that will make nvcc use the proper compiler. This helps keeping the system in a proper state, keeping the newest compiler, but nvcc (only nvcc) will use the old compiler version.
Doing some research online shows several methods for accomplishing this task. I just tested the method found here: http://www.vectorfabrics.com/blog/item/cuda_4.0_on_ubuntu_11.04 and it worked like a charm for me. It steps you through installing gcc 4.4 and creating scripts to run that version with nvcc. If you prefer trying the method mentioned in your post I'd recommend following that first link to install gcc4.4 and then create symbolic links as mentioned in your post. Creating symbolic links in Linux is accomplished by using the 'ln' command.
For example:
ln -s [source file/folder path] [linkpath]
This link gives a few examples of creating symbolic links on both Ubuntu and Windows: http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/. Hopefully that points you in the right direction.
I guess you may try the new, beta, version, that based on LLVM.
Another way to make nvcc work with non-default compiler (unlike #Sluml's answer, it allows more flexibility):
At first, just like #Slump proposed, you need to create directory ~/local/gcc-4.4/, and then create there symlinks for right versions of gcc: for i in gcc gxx; do ln -s /usr/bin/${i}-4.4 ~/local/cudagcc/${i}; done. Now when you run nvcc -ccbin ~/local/gcc-4.4/ ... nvcc will use correct versions of gcc.
Here is small CMake snippet of forcing nvcc use specific host compiler.
option (CUDA_ENFORCE_HOST_COMPILER "Force nvcc to use the same compiler used to compile .c(pp) files insted of gcc/g++" OFF)
if (${CUDA_ENFORCE_HOST_COMPILER})
set (CMAKE_GCC_TEMP_DIR "CMakeGCC")
file(MAKE_DIRECTORY ${CMAKE_GCC_TEMP_DIR})
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_C_COMPILER} ${CMAKE_GCC_TEMP_DIR}/gcc)
execute_process(COMMAND ${CMAKE_COMMAND} -E create_symlink ${CMAKE_CXX_COMPILER} ${CMAKE_GCC_TEMP_DIR}/g++)
set(CUDA_NVCC_FLAGS -ccbin ${CMAKE_GCC_TEMP_DIR} ${CUDA_NVCC_FLAGS})
endif()
Referenceļ¼
I update my gcc from 4.4 to 4.6. Then I could not use nvcc to compile my code. Luckily, by using the method provided by the following link. I set my default gcc compiler back to gcc 4.4. Now, I could compile file using either gcc4.4 or gcc4.6. quit cool
http://ubuntuguide.net/how-to-install-and-setup-gcc-4-1g4-1-in-ubuntu-10-0410-10
My gcc compiler is at a custom location /my/path/hpgcc
I've downloaded the boost sources. Executed bootstrap.sh, but it fails because it runs with the default gcc.
Looking into it, I see that it fails at the first thing it does: building the Boost.Build engine:
gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
(fails because executed with the default gcc, and not my gcc version).
I've tried to change the gcc path in the user-config.jam file, but it doesn't help. Probably because the Boost.Build's build script boost_1_47_0/tools/build/v2/engine/build.sh doesn't use user-config.jam, and just uses the default locations.
Any solution?
Add the line:
using gcc : : /my/path/hpgcc ;
to user-config.jam. user-config.jam will usually be in /path/to/boost/tools/build/v2/, but you can put a custom user-config.jam or site-config.jam in any of the places listed here.
/my/path/hpgcc should be the full path to the g++ executable.
EDIT (Igor Oks) : What eventually solved the problem is that I edited boost_1_47_0/tools/build/v2/engine/build.sh to make it use my custom gcc.
We do this in our build environment by simply defining the PATH and LD_LIBRARY_PATH environment variables to pickup our desired GCC first.