Anyone have idea to develop FMILibrary(64 bit) for PyFMI package.
FMILibrary(32 bit) compiled successfully with PyFMI package.
thanks for your useful ideas in advance
There is nothing that needs to be done on the FMI library side to be able to compile it as 64bit. You need to grab the source from http://www.jmodelica.org/FMILibrary and use a C-compiler that supports 64bit then you are good to go.
A similar problem was encountered also here.
As for the FMILibrary, as far as I understand, it is nothing you have to compile with PyFMI. It is a prerequisite for the operation of PyFMI. What you need to do is compiling FMILibrary(check the required version for PyFMI from here) using a compiler. And do not forget to show the path of FMILibrary to PyFMI.
What I would suggest, as in the first link stated, is installing Anaconda and working in a created environment.
Related
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?
While I know this has been asked here before, it has been several years since the last time I can find, and there was no successful solution to this question, so here we go.
I have a copy of x64-bit SPSS for *nix that requires on a 32-bit python2.7.3 installation for extended functionality. Unfortunately for me, I run an ubuntu x64 machine, and I've been unable to compile 32bit python on it. I've been able follow both sets of instructions also tested at this link https://askubuntu.com/questions/29253/how-can-i-install-a-32bit-python-on-64-bit-ubuntu but have not had any success with it following the flags. Both resulted in the correct location/unicode settings, but compiled x64 versions. I've checked for missing packages, but none of the recommended packages seem to be missing.
Any help with compiling python (or even an alternative method) would be greatly appreciated. As it is, the only solution I can think of is to create a chroot jail.
Have you considered running 64-bit SPSS and using 64-bit Python?
I wrote a C program and works fine on Windows 7 and Linux, but when I execute it on Windows XP I get the error:
"_except_handler4_common could not be located in the dynamic link library msvcrt.dll"
I researched it and some people said to delete the DLL "dwmapi.dll" which I don't have, so that's not my problem.
Some one told me to use depends walker(depends.exe) to find who is using msvcrt.dll. I did and find that pcre library is using it and there actually is a problem with it, but I don't have any idea how to solve this. Can any one help me?
Here's image of what depends walker show me:
Reason possibilities (afaiu):
a) You linked to msvcrt.dll specifically when building - this should
not happen according to Microsoft support unless you specifically do
it.
b) Some other installed or copied program/driver on your XP that
links to "wrong" version of msvcrl.dll is being triggered.
Depending on what the reason is,
here are few ideas to resolve:
1) There might be some program/driver/etc. installation on your XP
machine that has introduced "Vista/Win7 related crap" onto it. It is
said (by the internets) that PCRE3.DLL belongs to "GnuWin32 Non-system
processes". That means you can try to find it and rename/delete it. Or
delete the program you that uses it.
2) Installing the redist for XP of the C++ redistributable that you
used to build on Win7 might help. This is link for VS2005: (darn..
use google - i can only give two links per post :P)
Rebuilding:
3) Just build the file from sources on your XP machine using some
VisualStudio version you can get on it. And check those VS project
properties!
4) Fix your build on Windows7. You might be linking to
_except_handler4_common in msvcrt.dll in your Windows 7 build. Make sure that you do not do that. You can specifically instruct the linker
not to link to it in VisualStudio project properties
"/NODEFAULTLIB:msvcrt80.lib". You also did not specify what are you
using for building. VS2005, VS2008, VS2010, gcc?
Answer based on educated guesses and Jeffrey Tan research here:
and research here:
(On behalf of OP)
The problem was with the pcre3.dll, as i've told before, and i simply change the version of it, I was using the version 7.x and change to 4.4 that calls pcre.dll instead of pcre3.dll, that solve my problem if any one have the same issue.
here is the link to the correct lib:
pcre-4.4-dll.zip
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.
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