while compiling I get the following warning:
/usr/bin/ld: warning: libgfortran.so.3, needed by /usr/openmpi-4.0.3rc4/lib64/libmpi_usempi.so, may conflict with libgfortran.so.5
It does create the .exe but when executing it an error occurs:
ideal.exe: error while loading shared libraries: libgfortran.so.5: cannot open shared object file: No such file or directory
I search for it to try and link it but it didn't work
whereis libgfortran.so.5
libgfortran.so: /usr/lib64/libgfortran.so.3
I don't have much knowlegde about linux or compilers and I'm working on a SUSE server without sudo permission. The gnu fortran compiler I'm using is in my home directory /home/gomezmr/gcc . Does anyone know how to solve this? Thank you.
Your OpenMPI library was compiled for a different version of GCC/gfortran than the version you are using for compiling. The MPI library must be compiled for the same compiler version that you are using for compiling.
In simple cases it may happen that it will somehow work anyway, but problems like yours can happen. When using the mpi or mpi_f08 modules, the major release version must match (e.g. both GCC9 or both GCC 11,...).
Related
I am porting a large C++ library (libcoro.so) and example application (coro-example.cpp) from Windows to RedHat Linux 7.4. I have very little development experience on Linux, so this is probably a 'newbie' question. I have libcoro and the example app compiling, linking, and running on my RHEL 7.4 VM. However, the gcc linker fails to link the app on the customer's RHEL 7.4 machine when he tries to link coro-example.o to libcoro.so. The error message is:
/usr/bin/ld: warning: libusb-0.1.so.4, needed by ./bin/libcoro.so not
found (try using -rpath or -rpath-link) libcoro.so: undefined
reference to 'usb_open' libcoro.so: undefined reference to
'usb_release_interface' ...etc...
Running 'ldd coro.so' on my machine displays:
libusb-0.1.so.4 => /lib64/libusb-0.1.so.4 (0x00007f71115db000)
...etc...
And on the customer's machine:
libusb-0.1.so.4 => not found [many other libs] => not found ...etc...
Indeed, these libraries are in my /lib64 folder, but are not in the customer's. I'm not sure how they got installed on my machine. I have access to the missing libraries and can deliver them with my libcoro.so library. I really want my app to be self-contained and run on any RHEL 7.x machine. My question is:
What is the best way to identify which libraries are not part of the RHEL 7.x installation and have the linker fail on my machine if I'm not delivering a local copy? I tried linking with -nodefaultlibs, but the link fails on functions like printf() and I haven't found a way to locate these standard libraries. They don't appear to be in /lib64.
Is there a way to exclude /lib64 from the default library search?
There is a linker switch -Wl,--no-undefined which seems to do what I want. It fails to link and generates an error is the library is isn't explicitly named. Also, the command ldd libcoro.so lists all dependencies and where they are being resolved. I also found this this article very helpful.
I am installing Open MPI v1.8.8 with CUDA v7.5 on my Linux Debian.
I have tested CUDA and it works, tested OpenMPI and it works too. But when i try to combine them into a program, i meet an error: cannot find cuda.h file . This is my scenario:
My program source code include these .h file
include "cuda.h"
include "mpi.h"
I run command:
mpicc <filePath> -o test
And error appear:cuda.h: No such file or directory
#include "cuda.h"`
omp_info give me : mca:mpi:base:param:mpi_built_with_cuda_support:value:false
I have googled , and i followed some methods i found:
./configure --with-cuda
./configure --with-cuda=/usr/local/cuda-7.5
( source link : http://mirror.its.dal.ca/openmpi/faq/?category=buildcuda)
After that, i remake all , remake install Open Mpi. I run: mpicc or mpirun, the compiler give me error : mpirun error mca: base: component find: unable to open /usr/local/lib/openmpi/mca_mpool_sm
I set up soft link : ln -s /usr/local/cuda/include /usr/include ( describe in link : Building CUDA-aware openMPI on Ubuntu 12.04 cannot find cuda.h).
But it cannot fix my issue.
Does anyone successfully install it? Please help me or share your experience.
Thanks.
I think you are confusing installation problems with incorrect compiler options. It will be necessary to explicity specify the include paths, library paths, and libraries for CUDA when compiling and linking host code with your mpi wrapped host compiler.
Something like:
mpicc -I/usr/local/cuda-7.5/include -L/usr/local/cuda-7.5/lib -o test <filePath> -lcuda
would be the normal way to build a simple MPI program which call the cuda driver APIs. You will need to add nvcc compilation for device code and host code which uses the runtime API.
The apparent lack of CUDA support in your MPI flavour is a separate question and one you should probably take up in another forum (like the user mailing list of the MPI flavour you use).
I am trying to cabal install a component of wxHaskell (Haskell platform 2013.2 against wxWidgets 3.0).
I was able to compile the git version with 32 bit mingw from mingw.org. But in the end, the installed wx cannot function correct, and running a minimal example gives runtime exceptions in wxc.dll. So I try to compile the same thing under TDM-GCC 4.8.1 64bit, since the wxWidgets people provide their binary in the form of TDM-GCC compiled binaries.
But I immediately run into compilation errors with TDM-GCC, telling me
error: 'strnlen' was not declared in this scope
What surprises me is that even though both mingw32 and TDM-gcc uses the same external gcc from Haskell Platform c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe, one would give an error while the other compiles fine.
The first file causing problem is src\cpp\eljaccelerator.cpp. It compiles OK under mingw32:
...
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/MinGW/msys/1.0/local/include/wx-3.0 -IC:/Min
GW/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_LAR
GEFILE_SOURCE=unknown -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerato
r.cpp -o dist\build\src/cpp/eljaccelerator.o
but gives an error under TDM-gcc:
Building wxc
c:\HaskellPlatform\2013.2.0.0\mingw\bin\gcc.exe -Wl,--hash-size=31 -Wl,--reduce-
memory-overheads -Isrc/include -IC:/mingw/msys/1.0/local/include/wx-3.0 -IC:/min
gw/msys/1.0/local/lib/wx/include/msw-unicode-3.0 -D__WXMSW__ -DWXUSINGDLL -D_FIL
E_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -DBUILD_DLL -c src\cpp\eljaccelerator.cpp
-o dist\build\src/cpp/eljaccelerator.o
In file included from C:/mingw/msys/1.0/local/include/wx-3.0/wx/crt.h:19:0,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/string.h:4305,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/memory.h:15,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/object.h:19,
from C:/mingw/msys/1.0/local/include/wx-3.0/wx/wx.h:15,
from src/include/wrapper.h:20,
from src\cpp\eljaccelerator.cpp:1:
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const char*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:173:92: error: 'strnlen' was n
ot declared in this scope
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h: In function 'size_t wxStrnlen
(const wchar_t*, size_t)':
C:/mingw/msys/1.0/local/include/wx-3.0/wx/wxcrt.h:187:95: error: 'wcsnlen' was n
ot declared in this scope
Failed to install wxc-0.90.1.1
I was wondering if anyone has any similar experience. Any idea what went wrong and how to fix compilation for TDM-GCC? I tried adding #include <cstring> to wxcrt.h but it doesn't change anything.
FYI, I have compiled wxWidgets 3.0.0 from source in mingw and tdm-gcc versions respectively, using
./configure --enable-stl && make && make install
I can provide more details if needed.
First of all, wxWidgets certainly does work with MinGW, the fact that only TDM binaries are provided simply means that someone volunteered to provide the latter but not the former. But all three popular versions of MinGW (the two already mentioned and MinGW-w64) do work, so there must be something wrong with the build...
However while they all work, they are certainly different compilers, so what do you mean that they both use the same gcc binary? It must be either a MinGW one or a TDM one, but it can't be both at once.
It's also very suspicious that the configure detects different flags to use for the large file support. Look at config.log, something must have gone wrong and there must be some errors in the initial stage in it.
I'm attempting to compile a relatively simple Fortran executable so that it can be passed around to other Windows users that don't have Cygwin (or something of the sort) installed, however, I'm unable to get the executable to operate as a standalone. I've tried gfortran -static file.f and gfortran -static-libgfortran file.f, however other users always encounter this error:
The program can’t start because cygwin1.dll is missing from your computer. Try reinstalling the program to fix this problem.
From what I've read online (e.g. here), the -static option should be sufficient. I have verified that running the executable from my machine (DOS prompt) does work.
I have gcc (gfortran) version 4.7.3. I should also point out this is my first attempt at compiling portable Fortran.
Update
After realizing that this isn't a gfortran-specific issue (thanks to replies here), searches led me to related posts here and here
This is partially explained in the Cygwin FAQ. The solution is to install the mingw64-i686-gcc-fortran package with its dependencies, and cross-compile your code with i686-w64-mingw32-gfortran -static.
Just package the cygwin1.dll along with your binary file (both in the same folder) then it will run just fine.
I'm in the process of attempting to port some code across from PC to Ubuntu, and am having some issues due to limited experience developing under linux.
We use CMake to generate all our build stuff. Under windows I'm making VS2010 projects, and under Linux I'm making Eclipse projects. I've managed to get my OpenCV stuff ported across successfully, but am having major headaches trying to port my threaded boost apps.
Just so we're clear, the steps I have followed so-far on a clean Ubuntu 12 installation. (I've done 2 clean re-installs to try and fix potential library cock-ups, now I'm just giving up and asking):
Install Eclipse and Eclipse CDT using my package manager
Install CMake and CMake Gui using my package manager
Install libboost-all-dev using my package manager
So-far that's all I've done. I can create the eclipse project using CMake with no errors, so CMake is successfully finding my boost install. When I try and build through eclipse is when I get issues; The app I'm attempting to build uses boost::asio for some UDP I/O and boost::thread to create worker threads for the asio I/O services. I can successfully compile each module, but when I come to link I get spammed with errors such as:
/usr/bin/c++ CMakeFiles/RE05DevelopmentDemo.dir/main.cpp.o CMakeFiles/RE05DevelopmentDemo.dir/RE05FusionListener/RE05FusionListener.cpp.o CMakeFiles/RE05DevelopmentDemo.dir/NewEye/NewEye.cpp.o -o RE05DevelopmentDemo -rdynamic -Wl,-Bstatic -lboost_system-mt -lboost_date_time-mt -lboost_regex-mt -lboost_thread-mt -Wl,-Bdynamic
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `void boost::call_once<void (*)()>(boost::once_flag&, void (*)()) [clone .constprop.98]':
make[2]: Leaving directory `/home/david/Code/Build/Support/RE05DevDemo'
(.text+0xc8): undefined reference to `pthread_key_create'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::interruption_enabled()':
(.text+0x540): undefined reference to `pthread_getspecific'
make[1]: Leaving directory `/home/david/Code/Build/Support/RE05DevDemo'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::disable_interruption::disable_interruption()':
(.text+0x570): undefined reference to `pthread_getspecific'
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/libboost_thread-mt.a(thread.o): In function `boost::this_thread::disable_interruption::disable_interruption()':
(.text+0x59f): undefined reference to `pthread_getspecific'
Some Gotchas that I have collected from other StackOverflow posts and have already checked:
The boost libs are all present at /usr/lib
I am not getting any compile errors for inability to find the boost headers, so they must be getting found.
I am trying to link statically, but I believe eclipse should be passing the correct arguments to make that happen since my CMakeLists.txt includes SET(Boost_USE_STATIC_LIBS ON)
I'm officially out of ideas here, I have tried doing local builds of boost and a bunch of other stuff with no more success. I even re-installed Ubuntu to ensure I haven't completely fracked the libs directories and links with multiple weird versions or anything else. Any help would be muchly appreciated.
Correct mechanism is to use Threads package:
find_package(Threads)
#...
target_link_libraries(my_app ${CMAKE_THREAD_LIBS_INIT} ...)
See also cmake and libpthread
When you are building your targets, add -lpthread and it will compile.
See this other thread.
OK, so I found the solution.
It was to do with the absence of the -lpthread flag in the link command. In order to get CMake to link appropriately, then the TARGET_LINK_LIBRARIES line needs to be edited. My edit is:
Original:
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} )
Modified and working:
IF(WIN32)
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} )
ELSE(WIN32)
TARGET_LINK_LIBRARIES( RE05DevelopmentDemo ${Boost_LIBRARIES} pthread )
ENDIF(WIN32)
I'm guessing that I should probably change the ELSE(WIN32) to an elseif for or use the CMake command FindThreads to link in pthread if needed, but I'm not sure how to do that at the moment and have more imporatant things on my plate given the time I've lost. Interestingly enough, I noticed my link command now has two -lpthread flags appended at the end, one after another, but everything is still compiling quite happily.