I recently switched my PC at work from Ubuntu to Arch Linux.
And I am now getting the following error (I am using stack to build my project):
setup-Simple-Cabal-1.22.4.0-ghc-7.10.2: Missing dependency on a
foreign
library:
* Missing C library: HSrts-ghc7.10.2
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
As far as I understand it, the difference in Linux Distribution should not cause any issue.
Things I have tried:
-add the path where the library is with --extra-lib-dirs
-make sure that the version of stack/ghc are the same acrose both systems
-tried unsucesfully to find a relevant difference between the 2 systems
(gcc version was different but didn't change anything)
I have a docker container based on ubutu where it builds without an issue.
The only thing I can think of is that this library gets handled differently from some random C-library since it contains the Haskell-Runtime. But I have no idea what this difference would be. Or how a differnent handling would cause an issue on my Arch System.
Here my .cabal file (the folder also contains the whole project):
https://github.com/opencog/atomspace/blob/master/tests/haskell/libExecutionOutputTest/opencoglib.cabal
Okay i figured out a workaround, instead of specifiyc the library in the .cabal file:
...
extra-libraries: HSrts-ghc7.10.2
...
you add it to your stack.yaml file:
...
ghc-options:
package-name: -lHSrts-ghc7.10.2
...
If you also have a exectuable defined in your .cabal file this will break the executable, since the library is not only included in the library. And including the runtime library in an executable results in an instant segementation fault.
Related
I have a Windows 7 64bit system with the latest MinGW (32bit) installed along with the Qt 5.5 SDK (again 32bit) which also ships with its own MinGW. Due to the fact that I'm not the only one using the system I can't remove the standalone MinGW.
My project is using qmake and is a plain C project (not C++). Everything builds fine but when I try to execute my binary in the command line I get that the application was unable to start due to a missing libgcc_s_dw2-1.dll on the system.
After looking into the issue I found that both the standalone MinGW and the one shipped alongside the Qt SDK have the mentioned DLL.
Standalone MinGW - libgcc_s_dw2-1.dll is located inside the bin subdirectory of the MinGW installation where the binaries are located (gcc, g++, gdb etc.)
Qt MinGW - libgcc_s_dw2-1.dll is located inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\lib subdirectory while the MinGW components' binaries are inside C:\Qt\Tools\mingw492_32\i686-w64-mingw32\bin.
I would like to know how to properly set my PATH variable so that:
The application starts properly
No conflicts with the standalone MinGW installation occur
Just a side-note: I've already checked other posts here on SO but was unable to find a solution (perhaps I've missed it). I have also tried LIBS += -static but the result is the same.
You just need to copy this dll with your executable, i.e.:
cp <path-to-qt-install-dir>\qt5.7.0\5.7\mingw53_32\bin\libgcc_s_dw2-1.dll <path-to-dest-dir>
You mat find that you have other dependencies, to see which other deps you have you can use: ldd <your-executable>. You only need to copy the qt specific dlls you can see these by:
ldd <executable> | grep -i qt
note
You can statically link it with:
linker commands like -static-libgcc or -static, but I think you start to hit LGPL issues and also you may need to statically compile qt from source - can't recall for this particular file.
note2
Sorry ldd is for linux, just realized you have windows, in which case you can use one or both of:
dependency walker: from here
<path-to-qt-bin-folder>\windeployqt.exe <path-to-your-executable>
I have mixed results with windeployqt, but if you have any plugins its quiet good for getting that part sorted.
#include <stdio.h>
int main(void)
{
printf ("Programming is fun");
return 0;
}
When I use the cc command in terminal to compile the above program it returns
fatal error: 'stdio.h' file not found`
I compiled this exact code on ubuntu where it created an a.out-file, which sadly did not run either. While I'm not sure why either happens at least no error was produced on ubuntu.
For recent macOS, people would miss C headers after system update.
cd /Library/Developer/CommandLineTools/Packages
open macOS_SDK_headers_for_macOS_xx.pgk
I guess this is another Apple's bug.
You don't specify the platform you're on...
If stdio.h is not found, it usually mean you don't have the necessary header files on your system (usually in /usr/include/).
Your compiler might be working fine, but it looks like the C-Library headers are not installed.
Depending on your platform, you'll have to install them.
It's a bit weird that you have a working compiler without C library headers.
You may want to reinstall your compiler, or search for a package which contains the headers for the C library.
If you're on OS X, (re)install Xcode as well as the command line tools.
If you're on Linux, use your package manager to install the development package for C (e.g. libc6-dev on Debian).
Before you go reinstalling your compiler you might want to check your include paths. As you don't specify your platform I can only provide general information but this is similar on many platforms.
Using cc you need to set them in the environment. Try typing 'env' to see your current settings. There needs to be a line that sets a variable 'include' with the full path to the location of your studio.h.
You can also set the include path in the make file or, if using an IDE, in the project settings.
There is something wrong with how your compiler is configured.
I have a project written in C that I am porting to an older system CentOS release 5.10 (Final)
For our newer system Fedora 20 we are using apr-1.5.0, these won't work on CentSO as I get the link problems there.
tools/apr/libs/libapr-1.so: undefined reference to `memcpy#GLIBC_2.14'
tools/apr/libs/libapr-1.so: undefined reference to `epoll_create1#GLIBC_2.9'
tools/apr/libs/libapr-1.so: undefined reference to `dup3#GLIBC_2.9'
tools/apr/libs/libapr-1.so: undefined reference to `accept4#GLIBC_2.10'
So I downloaded the older apr-1.2.7 libraries and headers and I compile and link with them and everything works OK.
However, I am using cmake and I have to adjust the path everytime I switch from different operating systems.
For CentOS I have to use this:
link_directories(${PROJECT_SOURCE_DIR}/tools/apr-1_2_7/libs)
And for a newer system I have to modify and use this:
link_directories(${PROJECT_SOURCE_DIR}/tools/apr/libs)
I am just wondering if there anyway cmake can detect the system and then use the appropriate libraries.
if(CSENTOS_5_10)
link_directories(${PROJECT_SOURCE_DIR}/tools/apr-1_2_/libs)
else
link_directories(${PROJECT_SOURCE_DIR}/tools/apr/libs)
endif
I was thinking of creating a toolchain file, but I think that would overkill for just a small thing.
I cannot use the apr that are installed using yum, as there is no guarantee that the libraries and headers have been installed.
Many thanks for any suggestions.
You're doing it wrong(tm).
See the docs:
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:link_directories
You should be using find_library instead, with hints of where to look for the library.
You can then put such a thing in a Find-module.
I was trying to build gdal-1.10.0
(http://trac.osgeo.org/gdal/wiki/DownloadSource) using mingw64 (from
http://sourceforge.net/projects/mingwbuilds/files/host-windows/
x64-4.8.0-release-posix-seh-rev2.7z). I have compiled gdal-1.10.0 under the
standard MinGW (32-bit) version without a problem.
The reason I have to switch to mingw64 is that the standard 32-bit MinGW distribution
does not support c++11 features like std::thread, and (I suspect) other features as
well. But I get an linking error in the end telling me something about
undefined reference to '__imp_GetACP'
(or a different decorated name if I use the 32-bit variant from
mingw64/mingw-builds). BTW, I tried different versions of mingw64, including
64-bit, 32-bit, seh, sjlj, but all gave the same error about GetACP().
I did some homework and found some instructions for a similar compilation task:
http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env
According to the above website, it seems that they suggest the problem has to do
with WOW64 and the correct version of windows dll files cannot be used because
windows automatically determines it for you depending on whether a 32-bit or
64-bit application making the call. This is supposedly a problem for mingw64
because the compiler gcc is 64-bit but msys is hopelessly 32-bit.
But since I tried 32-bit versions as well, the above does not seem to explain
the error.
Even more, I tried in a dirty way to comment out all calls to GetACP(),
because I don't really care about code pages and all that for my purposes.
Strangely enough, compilation is OK (on a fresh source just with the GetACP()'s commented out), but the same link error is still reported. I checked that libkernel32.a, libiconv.a are in the lib folder, and also followed the instructions in the blog above to copy dll's out from
c:\windows\system32 and place them in mingw subfolders with appropriate renaming. The link error remains. This is where I stopped hacking after spending almost two days on this without success. I can't understand why the entire source-code does not contain a single call to the function and I am still getting the link error.
Can anyone explain what might have caused this issue between gdal and mingw64,
and how to fix it?
Also, a general question about mingw64 is that is it really able to support
posix functions? I see package names such as
x64-4.8.0-release-posix-seh-rev2.7z, but I remember that the MinGW people said
they will never support full posix.
P.S.
I am testing this on a Windows Server 2008 R2, 64-bit.
Update:
The complete steps for building gdal-1.10.0 under MinGW64 (mingw-builds) are:
$./configure
Then,
Edit GDALmake.opt, Find GDAL_ROOT and replace the cygwin drive format with dos/mingw format, e.g.
Change:
GDAL_ROOT = /d/temp/build/gdal-1.10.0
to
GDAL_ROOT = d:/temp/build/gdal-1.10.0
Replace
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
with
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
Finally,
$ make && make install && cp apps/*.exe /usr/local/bin/
I have accidentally encountered the same problem.
Maybe this is a MinGW bug or bad configuration files, but the solution is to add
-liconv to the end of linker flags, for example, replace
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
with
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
in GDALmake.opt file (found by searching Mingw directory for GetACP in files).
I have my own program with plugins (dynamic shared libraries) on a linux (ubuntu) system. My libraries (plugins) use OpenCV (maybe not so important).
My plugins are in /usr/local/lib/mysoft/.
I have compiled my program successfully even with libraries, successfully installed so everything seems to be OK up to this point.
When I run my program, it loads a bunch of these libraries based on some configuration file. I have several libraries which are loaded successfully but I cannot load one library. It gives me error when loading (used dlopen() to open the library):
/usr/local/lib/mysoft/libMyPlugin2.so: undefined symbol: _ZN2cv6resizeERKNS_11_InputArrayERKNS_12_OutputArrayENS_5Size_IiEEddi
Segmentation fault (core dumped)
Tue Nov 20 19:11:29 CET 2012
It obviously has some problems to find cv::resize which is part of OpenCV but I don't understand why.
I checked following things:
OpenCV is probably correctly installed since other libraries use it as well and are loaded without problems
no dependencies of my program, libMyPlugin2.so or OpenCV are missing (checked with ldd)
Architecture of all libraries and binaries seems to be the same (I checked it with objdump -f)
Does anybody have an idea what am I doing wrong?
This post seems to be so relevant but still didn't help:
Linux shared library that uses a shared library undefined symbol
Well I found the problem, hopefully it can help others...
The problem - I was missing one OpenCV library when compiling. So I replaced "opencv_core opencv_highgui" by "opencv_core opencv_imgproc opencv_highgui" and everything works.
So although I was able to compile it one of the dependencies was missing - I guess something has changed in OpenCV cause these sources worked perfectly (even with build) with older versions of the OpenCV.