I have source code that was not written by me, and I cannot contact the author. It is written in C++ and requires libjpeg, boost, and the Intel Performance Primitives.
Compilation was a chore, but after days of problem solving, it compiles. Now, I get the following runtime error: error while loading shared libraries: libippi.so.5.1: cannot open shared object file: No such file or directory. The error occurs immediately regardless of the command line arguments.
I downloaded the trial version of IPP for Ubuntu 9.04. Under /opt/intel/ipp/6.1.2.051/ia32/sharedlib/, I see a bunch of files beginning with lib* and libippi*, including libippi.so.6.1. So I thought I would try to create a link libippi.so.5.1 that points to libippi.so.6.1, but that doesn't work. I tried creating a similar link in the local directory, and that does not work either.
I am not familiar with any of these libraries, so I don't know what else to try. I could not find any solutions on the net or SO. If you could kindly help me fix this error, I would greatly appreciate it. Thank you.
I know its been a while, but theres a solution here that helps with the problem
http://www.w-bremer.de/en/howtos/72-opencv-ubuntu-ipp :)
Looks like the app is compiled against an older version of IPP. Since 6.1.2 is called libippi.so.6.1, it may be as simple installing IPP 5.1.x (though linux library versioning isn't as simple as this.)
If you create a login for the intel non-commercial IPP download area, you can dig around and see if they offer older builds.
Alternatively, doing a quick google search I found this FTP site which seems to have it but note I have not actually downloaded or tried this code, and can not verify if this is a legal mirror or not or if it is the original Intel libraries, you will need to do your own due dilligence before using this code
http://21cma.bao.ac.cn/software/21cma/intel/ipp-5.1.1.005/
Note that to use this older version of IPP in a modern Ubuntu, you may need to get older versions of other libraries it depends on (the requirements are listed in the Release Notes), or even just run it under a chroot of a supported Linux Distro at least to test if it fixes your issue.
Related
I've been trying to find a way to make my applications compatible between different Ubuntu LTS versions.
However, most of the time it ends up with the "symbol lookup error:" or "cannot find libxxxx.so.xx".
The requirement is very clear, developer should be able to compile the code on one of last 3 Ubuntu LTS (currently 12,14,16-04) versions and the output should be able to run on all 3 last versions. But the problem is getting complex.
Is there any way to do this?
Thanks in advance.
Linux binaries compiled on older distributions are generally compatible with newer ones. The kernel invests a lot of effort in being backwards compatible - as does glibc. This may not be true for all libraries, but in my experience; most try.
So, what you probably want to do is, compile your app on the oldest supported distro and it will most likely work on the newer one(s).
A really simple trick is to ... compile from source on the appropriate distro.
You can even almost automate this as Ubuntu / Canonical give you free accounts on Launchpad. For example, I use my PPA for either backports or unpackaged sources I want at either work, or home, or on Travis CI, ... in a particular release flavour.
Otherwise, the very obvious alternative is of course to create a static build which is independent of the runtimes of the particular release. That will work 'forever' or until the kernel changes. In the 20+ years I have used Linux, such a change occurred once (with the introduction of the Elf format).
I've come across an issue whilst trying to compile the latest branch of grpc under MSYS2, using mingw64 as suggested by the official installation guide.
The latest gcc for msys2 is 5.2.0, which isn't exactly on good terms with grpc. Still, downgrading to 4.9.1 helped a bit. Through a lot of manual editing of the makefile and a couple C headers, I was finally able to compile all the dependencies. As far as I can tell, most objects had successfully compiled. However, make keeps failing with the error "no target to make libgrp.dll, required by shared_c"(might not be perfect wording). I end up with botched static libs that are recognized by Qt as lacking symbols.
I would greatly appreciate a reliable compilation guide for grpc, and/or precompiled binaries fit for Qt 5.5 32-bit. I know the project is not too mature just yet, but it looks very promising and I can't wait to work with it!
Many thanks!
You're right that mingw isn't quite a first class citizen for grpc, but it's something we're looking to work on soon. Please file bugs at http://github.com/grpc/grpc/issues for anything you find!
That said, we do test the C codebase against Visual Studio 2013 regularly. I expect C++ to be tested regularly soon, along with VS2015. Could VS2015 be the solution to your problems, given it's now a free download?
First some back story:
I dont know what im doing.
Thats a lie, I know a bit about what I'm doing. I'm a web developer so looking at code isn't all gibberish, but trying to use Xcode is a new book for me. Anyway, I designed a game that was compiled in C++ using SFML on Windows, and now we are trying to bring it over to OS X (I am the only one of the group with a Mac).
Using Xcode 4.6.1 and SFML 2.0 I've been trying to get this damn application to build, and so far it's been nothing but headaches. The current state of getting this thing to work is not so bad, it finally builds with no errors but the build stops and this shows up:
dyld: Library not loaded: #executable_path/../Frameworks/freetype.framework/
Versions/A/freetype
Referenced from: /Users/Eric/Library/Developer/Xcode/DerivedData/
Test-haconqzbewevbwgukppsacykkpml/Build/Products/Debug/Test.app/
Contents/Frameworks/sfml-graphics.framework/Versions/2.0.0/sfml-graphics
Reason: Incompatible library version: sfml-graphics requires version 17.0.0 or
later, but freetype provides version 16.0.0
I just dont understand this error. I have the most updated version of FreeType. I'm not even sure what that version number is referring to considering FreeType is at 2.4.11. I can't seem to find this error anywhere else either, any ideas?
The version numbers mentioned in the error message refer to the compatibility version of the library. This is a version number that's baked in to a given dynamic library at the time it is built. When another binary is linked against that library, the compatibility version is copied in to the LC_LOAD_DYLIB load command that tells dyld at runtime which dynamic libraries need to be loaded. When a library is loaded by dyld, the compatibility version is checked and if the program's version is greater that the library's version, it is an error.
When you run otool -L freetype.framework/Versions/A/freetype you'll see that it reports its compatibility version as 16.0.0. If you run it on sfml-graphics.framework/Versions/2.0.0/sfml-graphics you'll see that it reports a compatibility version of 17.0.0 for freetype.framework. So you're hitting the error case described above.
The most common cause of an error like this is running your application against an older version of a framework than the version you built it, and any linked frameworks, against. Note that "older" in this sense refers to the compatibility version and not any other version number associated with the framework (e.g., the marketing version).
Without knowing the origin of the two frameworks involved (e.g., if you built them yourself, or where you got the binaries from), it's not completely obvious where you've gone wrong. I will note however that the SFML git repository appears to have a version of freetype.framework with the appropriate compatibility version (17.0.0), so if you're using a binary of sfml-graphics.framework provided by the SFML folks then picking up their FreeType framework may be your solution.
I am trying to modify a current MFC application running on Windows NT4 to use boost libraries for ethernet communcications (originally, it used CommX for serial) and general increased performance, effieciency, and clarity of code.
I started out modifying it in VS2010, but I found that I was unable to produce a valid NT4 app with VS2010. I googled the issue and found that VS2005 was the last version able to create an NT4 app. I got everything to compile in VS2005, but found that I had to change certain #define statements in stdafx.h in order to get the app to run on NT4. However, even after doing that, when I execute the program on NT4, it immediately quits with no error. It doesn't show anything. I even checked the Task Manager processes while executing it. It is like it never executed at all.
I got desperate and tried compiling the app in VS2003, but I got so many errors that I gave that up.
My last attempt was VC6, but again, I got 262 errors and started wondering whether it was even possible for boost to run in VB6 or on an NT4 machine.
Is it even possible to compile and run an MFC app with boost libraries on an NT4 machine? If so, which environment/compiler do I need and how do I configure it to work correctly?
This is a very tight-schedule project, so any (prompt) help would be very appreciated! Thank you!
If you're trying to use VC6 to compile code that uses Boost, you may need an older version of Boost. Try 1.34.1.
You might try using STLport as the standard library implementation instead of the built-in STL that comes with VC6. I'm using boost 1.32 and STLport 4.6.2 successfully in VC6 with an MFC project. I haven't tried moving up to newer versions of boost or STLport, but STLport might be enough to get you going.
More out of interest than anything else, but can you compile a DirectX app under linux?
Obviously there's no official SDK, but I was thinking it might be possible with wine.
Presumably wine has an implementation of the DirectX interface in order to run games? Is it possible to link against that? (edit: This is called winelib)
Failing that, maybe a mingw cross compiler with the app running under wine.
Half answered my own question here, but wondered if anyone had heard of anything like this being done?
I've had some luck with this. I've managed to compile this simple Direct3D example.
I used winelib for this (wine-dev package on Ubuntu). Thanks to alastair for pointing me to winelib.
I modified the source slightly to convert the wchars to chars (1 on line 52, 2 on line 55, by removing the L before the string literals). There may be a way around this, but this got it up and running.
I then compiled the source with the following:
wineg++ -ld3d9 -ld3dx9 triangle.cpp
This generates an a.out.exe.so binary, as well as an a.out script to run it under wine.
If this is not about porting but creating, you should really consider OpenGL as this API is as powerful as DirectX and much easier to port to Mac or Linux.
I don't know your requirements so better mention it.
You can't link against wine as it's essentially a call interdictor/translator rather than a set of libraries you can hook into. If linux is important go OpenGL/SDL/OpenAL.
I believe(I've never tried this) you can can compile Linux binarys against winelib. So it works just like a Linux executable, but with the windows libraries.
http://www.winehq.org/site/docs/winelib-guide/index
go to the directory with the source and type in:
winemaker --lower-uppercase -icomdlg32 -ishell32 -ishlwapi -iuser32 -igdi32 -iadvapi32 -ld3d9 .
make
wine yourexecutable.exe.so
If you get this Error:
main.c:95:5: error: ‘struct IDirect3D9’ has no member named ‘CreateDevice’
make sure you have named your file main.cpp and not main.c.
There is currently no way to compile DirectX code to directly target Linux. You would build your application like you normally would, then run it using a compatibility layer like Wine/Cedega.
you can compile a directx apps in linux, but not launching it straight away.
if you use a crosscompilator that makes windows exe and point to the windows sdk and directx sdk.
Although this question is dated, I decided to updated on it, because it keeps popping up for me as the first suggestion for this particular problem.
As the previous answers already suggested you can compile against winelib. However, there are yet another two solutions.
The first solution would be either to use the MinGW provided for your distributions. MinGW is a 'cross-compiler', that compiles either from macOS or linux to windows and has support for DirectX. Note, that C++ libraries compiled with MinGW are not compatible with the MSVC compiler's ABI, thus cannot be consumed. However, the resulting binaries can be executed using Wine.
The second solution would be to use clang as a cross compiler. Clang usually includes the Compiler and Linker needed for Windows out of the box. However, it'll require you to include provide the headers and libraries yourself. On the other hand, libraries compiled this way are compatible with MSVC and, thus, can be consumed by it.
Side note:
Latter allows you to setup an CI server using linux (I did so on a raspberry pi), which creates compatible binaries for end users.
Wine is the only way to run DirectX in Linux