I am having this strange error when compiling a simple code using msys2:
The procedure entry point _gfortran_os_error_at could not be located in the dynamic link library
Other compiler implementations work fine.
Here is the code:
PROGRAM MAIN
IMPLICIT NONE
INTEGER :: N
REAL(8), ALLOCATABLE, DIMENSION(:,:) :: X
N = 10
ALLOCATE(X(N,N))
DEALLOCATE(X)
END PROGRAM MAIN
The compiler is GNU Fortran (Rev6, Built by MSYS2 project) 11.2.0
The compiling method is
gfortran -o main.exe main.f90
I noticed that when I link the program with -static it surprisingly works. I am not sure if this is a common problem with gfortran compilers.
Related
I've seen some versions of libc.so which, when executed from the command line, will print a version string, like so:
$ /lib/libc.so.6
GNU C Library (Buildrood) stable release version 2.30.
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTIBILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.4.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<https://www.gnu.org/software/libc/bugs.html>.
There's obviously some kind of entry point into this library, while still preserving main() for user programs.
I'd like to do this for my own library, to print useful information about how it was compiled, what it supports etc. My searches regarding this have not been fruitful, but perhaps I'm searching the wrong thing. How can I do this?
Position independent executables (PIE) are now the default on systems like Linux and OpenBSD [1]. So you can just build your shared library as you would a regular executable, and give the executable as an object argument to cc, LD_PRELOAD or dlopen() it as if it were a shared library.
The only thing you should make sure is that all the needed symbols are exported, which is NOT the default. So you should either use -Wl,-E (which would and cause it to export all symbols), or give it a list of exported symbols via -Wl,--dynamic-list=filename.
$ cc -Wl,--dynamic-list=<(echo '{func;};') -include stdio.h -o shared.so -xc - <<'EOT'
int main(){ printf("Shared library!\n"); }
void func(){ printf("Exported function!\n"); }
EOT
$ cc -include stdio.h -xc - -x none ./shared.so -o main <<'EOT'
int main(){ extern void func(void); func(); }
EOT
$ ./shared.so
Shared library!
$ ./main
Exported function!
The problem with -Wl,-E is that it will also export the symbols from the crt*.o startup files, which may cause the "main" executable to reference them instead of pulling its own copy of the startup code. That doesn't look like a good idea.
A solution which would allow you to still use -Wl,-E instead of listing all the exported symbols would be to use -Wl,--version-script=file with a version script which localizes main, __libc_csu*, _start and the rest of the zoo:
cc -Wl,-E -Wl,--version-script=<(echo '{local:_*;data_start;main;};') -include stdio.h -o shared.so -xc - <<'EOT'
int main(){ printf("Shared library!\n"); }
void func(){ printf("Exported function!\n"); }
EOT
$ ./main
Exported function!
[1] on some systems like FreeBSD or NetBSD you still have to use -pie -fPIE in order to build a PIE executable, but not to link against one.
I am currently working on a project, where I want to execute some code in Cuda, which should be called from the main c++ file. When I am compiling with Clang only the .cpp files are compiled and the compiler tells me "expected exprission" on the <<<>>> Kernel call notation. Any Idea how I can fix this?
I have a .cuh files with the definition which I am including and a .cu source file. I am using CMake to configure the project and building it with Ninja.
I am using ccached clang++ and supplying "--cuda-path=/usr/local/cuda-10.1 --cuda-gpu-arch=sm_61 -L/usr/local/cuda-10.1/lib64 -lcudart_static -ldl -lrt -pthread -std=c++17" to clang args.
When I add the -x cuda flag, the error does not appear, but instead it tells me that a library that I am linking against is not allowed to overwrite some host function, but I think this is because it wants to compile everything as cuda, which is not intended.
I am passing all files inside my source folder to add_executable in CMake via a GLOB ${APP_PATH}/src/*, which should add all files.
main.cpp
#include "ParticleEngine.cuh"
...
int main(){
simulation_timestep(&this->particles[0], this->gravity, 1, delta_frame,
this->particles.size());
}
ParticleEngine.cuh
#pragma once
#include "cuda_runtime.h"
#include "device_launch_parameters.h"
void simulation_timestep(Particle *particles, ci::vec3 gravity, double mass,
double time_delta, unsigned long long n_particles);
ParticleEngine.cu
#include "ParticleEngine.cuh"
__global__ void particle_kernel(Particle *particles, ci::vec3 *gravity,
double *mass, double *time_delta) {
...
}
void simulation_timestep(Particle *particles, ci::vec3 gravity, double mass,
double time_delta, unsigned long long n_particles) {
... //memcpy stuff
particle_kernel<<<dimgrid, dimblock>>>(cuda_particles, cuda_gravity,
cuda_mass, cuda_time_delta);
...
}
edit:
Full error message:
[build] In file included from ../src/main.cpp:1:
[build] ../src/ParticleEngine.cu:43:20: error: expected expression
[build] particle_kernel<<<dimgrid, dimblock>>>(cuda_particles, cuda_gravity,
[build] ^
edit:
Error message when executing clang with -x cuda:
[build] /home/mebenstein/Cinder/include/glm/gtx/io.inl:97:32: error: __host__ __device__ function 'get_facet' cannot overload __host__ function 'get_facet'
[build] GLM_FUNC_QUALIFIER FTy const& get_facet(std::basic_ios<CTy, CTr>& ios)
[build] ^
[build] /home/mebenstein/Cinder/include/glm/gtx/io.hpp:145:14: note: previous declaration is here
[build] FTy const& get_facet(std::basic_ios<CTy,CTr>&);
[build] ^
I am including the c++ library cinder in main.cpp and this error appears.
#include in C++ works by literally replacing that statement with the contents of the included file. As a consequence, the included file is also parsed as C++ code.
To compile a file as CUDA code, the file needs to be a separate compilation unit, i.e. given as an argument to the clang invocation. It also either needs to have a name ending in .cu, or the -x cuda flag needs to be given to clang.
Update after error messages have been included in the question:
It appears that Cinder does not support compilation of the CUDA part with clang++ because of a difference in how __host__/__device__ attributes are treated.
At this point your options are the following:
You can modify Cinder to also support clang++, it's open source.
You can ask the Cinder authors or third parties whether they are willing to make the necessary changes. A cash incentive may or may not increase willingness.
You can use nvcc to compile the code.
I feel completely lost trying to get CMake to work on Windows. I have a project (ECCODES) that has Fortran and C files. I can compile Fortran files if I don't use CMake. But this project came with a ton of CMake files. I look at the error below and it says to me, "I (CMake) cannot compile a simple Fortran program even though you can compile Fortran files when you aren't using CMake." Can anyone make sense of this? I'm trying to use mingw64 since I can't use cygwin on this project for the Windows build. On Mac OS X and GNU/Linux everything builds fine, but I have to run this project on Windows...
Error:The Fortran compiler "c:/gcc-5.1.0-tdm64-1-fortran/bin/gfortran.exe" is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/knauthg/.CLion2016.1/system/cmake/generated/ECCodes-45f4e5f3/45f4e5f3/__default__/CMakeFiles/CMakeTmp
Run Build Command:"C:/mingw64/bin/mingw32-make.exe" "cmTC_93cb8/fast"
C:/mingw64/bin/mingw32-make.exe -f CMakeFiles\cmTC_93cb8.dir\build.make CMakeFiles/cmTC_93cb8.dir/build
mingw32-make.exe[1]: Entering directory 'C:/Users/knauthg/.CLion2016.1/system/cmake/generated/ECCodes-45f4e5f3/45f4e5f3/__default__/CMakeFiles/CMakeTmp'
Building Fortran object CMakeFiles/cmTC_93cb8.dir/testFortranCompiler.f.obj
c:\gcc-5.1.0-tdm64-1-fortran\bin\gfortran.exe -c C:\Users\knauthg\.CLion2016.1\system\cmake\generated\ECCodes-45f4e5f3\45f4e5f3\__default__\CMakeFiles\CMakeTmp\testFortranCompiler.f -o CMakeFiles\cmTC_93cb8.dir\testFortranCompiler.f.obj
CMakeFiles\cmTC_93cb8.dir\build.make:64: recipe for target 'CMakeFiles/cmTC_93cb8.dir/testFortranCompiler.f.obj' failed
mingw32-make.exe[1]: *** [CMakeFiles/cmTC_93cb8.dir/testFortranCompiler.f.obj] Error 1
mingw32-make.exe[1]: Leaving directory 'C:/Users/knauthg/.CLion2016.1/system/cmake/generated/ECCodes-45f4e5f3/45f4e5f3/__default__/CMakeFiles/CMakeTmp'
Makefile:125: recipe for target 'cmTC_93cb8/fast' failed
mingw32-make.exe: *** [cmTC_93cb8/fast] Error 2
CMake will not be able to correctly generate this project.
Before, I was using the tdm-gcc Windows 64-bit build of gfortran. I switched to the 64-bit build of gfortran by Simply Fortran, and now the entire ECCODES project builds to completion using CMake. I'm still using MingW64 gcc to compile the C files.
Hat tip to John Wasilewski on a thread of Physics Forums who gave the tip about Simply Fortran.
I'm trying to compile / run in interpreter a program written by another programmer. This program uses this construct:
#load "unix.cma"
which I haven't encountered before. I've found this page: http://ocamlunix.forge.ocamlcore.org/generalities.html which mentions it, but typing this code into interpreter results in syntax error. Same thing happens when I run the file with this instruction through ocamlc. What am I missing?
ocamlc -v
The Objective Caml compiler, version 3.12.1
Standard library directory: /usr/lib64/ocaml
#load is a toplevel directive, which is not available in ocamlc nor ocamlopt compilers but only in OCaml toplevel (REPL) ocaml. See http://caml.inria.fr/pub/docs/manual-ocaml/manual023.html#toc91. Use the toplevel to run the program:
ocaml blahblah.ml
How can I compile a (Haskell) program so that it doesn't require DLLs?
I wrote a program that uses GLUT and requires glut32.dll. I compiled it with ghc --make program.hs. Now I want to distribute my program, but I don't want it to require any DLLs (so I can just give the .exe to the users). I tried compiling with ghc -static --make program.hs but it didn't work, I still get "user error (unknown GLUT entry glutInit)".
How can I do this?
This is only possible if GLUT provides a static version of the library (this could be named something like glut32s.lib but there's no requirement that they call it anything in particular).
The success of this approach will also depend on whether GHC allows linking with external static libraries at all. The man page for ghc indicates that -static applies only to the Haskell libraries, not other external libraries.
Assuming you have static versions of the required C libraries, you can create a static Haskell executable with:
ghc -O2 --make -static -optc-static -optl-static A.hs -fvia-C
which ensures both the Haskell components, and C components will be linked statically, via the C toolchain.