I'm trying to load a dll into my lua script and call the function. When I create the dll using GCC (under cygwin) and lua (5.2.4) I'm able to load the library & execute it without a problem.
However, when I create run the same script from SciTE, using Lua 5.1, the dll loads successfully. However, it does not execute. In the dll I'm trying to simply write two integers into a file.
t = package.loadlib("mylibrary.dll","myfunc")
t(23,45)
There are two questions here:
1. What format should the 'mylibrary.dll' be, for lua to understand and execute without problems - ELF or COFF.
2. Can I run dll (built under windows, obviously) under lua running on linux?
The question in your title seems to be very different from the cause of the problem you describe.
On the one hand, the format for dynamic libraries loaded by Lua is the format for the platform that the Lua code is running on. Just as you can't take a compiled Win32 executable and expect it to run on Linux, you can't take a compiled Win32 dll and expect it to load it on Linux. Obviously emulation tools like Wine exist, but those work by emulating Windows. You could run them within the emulator, but not outside of it.
But on the other hand, that is not the source of your problem. Your problem is that you're using a dynamic library that was built for one version of Lua with an application that was built for another version of Lua. That doesn't work; Lua does not retain compatibility between "minor" versions, only between revisions (Lua 5.1.3 vs. 5.1.4).
ELF or COFF, that isn't going to work.
Related
I'd like to build a Fortran program that will use a library with a specific interface, but I don't have the library currently installed on my system. I only need to compile the Fortran program, not run it. I assume that the system where my program is run will have the library installed in a standard location (i.e. /usr/lib).
Is this possible?
Specifically, I'd like to use the Conda-build system to compile a program that links to the MATLAB library (libmex). Since MATLAB is not installable with Conda or other package managers, I was hoping I could somehow build my program in such a way that it has the correct function call to libmex but requiring that users will have libmex installed in a place where my program can find it.
I use Cygwin to build source code to DLL used by windows app.
When I use GCC core / GCC g++, the app crash if it calls function (which includes printf or malloc) in DLL.
When I use Mingw64-x86_64-gcc-core / Mingw64-x86_64-gcc-g++ it reports error like sys/socket.h：No such file or directory.
Can anyone explain how to do it? Thanks.
The first problem is due to the tentative to build a stand alone DLL (not depending on cygwin1.dll) using cygwin only specific tools.
You have collision between multiple malloc and other C library call present in cygwin1.dll.
The second is due to the fact that sys/socket.h does not exist on Windows
see for possible solution:
Using sys/socket.h functions on windows
So you need to define what is your target : Cygwin/Posix or Windows and choose programming style and tools accordingly, you can not mix.
I've tried PyInstaller, but it doesn't support Python 3.7. I'm using Python 3.7 features, so I don't want to downgrade to 3.6. How can I make my program a single-file, cross-platform executable?
Have you tried to use cx_Freeze? For Python 3.7, you need to apply the bugfix described in this answer by hand to your local cx_Freeze installation until a corrected version has been released.
cx_Freeze itself does not support building a single-file executable, but you can use further tools for this purpose as described here.
This depends on what you mean by "EXE file".
If you can jam all your source code into a single.py file then that would likely be the closest to a cross platform executable. It would just require having a python interpreter pre-installed on each OS.
If you are referring to a literal .exe executable file that works cross platform; for python programs this is impossible. Python compiles down to machine code in the same way that C and C++ do, which is platform specific. Unlike Java, which runs on a VM, if you wish to compile your python program into a single executable file, then the file will only work on whatever platform it was compiled on.
I am trying to install some commercial software that was written in Java for a Windows computer operating system. I have downloaded Java from their site and I have also downloaded the JDK package for a 64bit windows system so to my knowledge I should have everything I need to have java work. I then create a shortcut of the java exectuable javaw.exe and edit the target path and the start in path to my specifications but when I go to execute it, it tells me that it "Could not create Java virtual machine".
Does anyone know how to fix this error?
Luke H
How are you creating the shortcut? In windows, this might not be the correct approach.
Does the installer use an embedded version of java? It is possible that the software uses some native libraries that aren't compatible with 64 bit java.
Depending on the setup script, it may be passing invalid command line arguments to the version of Java you installed.
Its a bit late, but this might help others later.
Here's what worked for me:
Target: "C:\Program Files\Java\jre1.7.0\bin\javaw.exe" -classpath C:\OLINDA olinda
Start in: C:\OLINDA
It seems that you don't know how properly start the Java Virtual Machine, in Windows, the JVM can be started with two executables one is java.exe and the other one is javaw.exe, both do the same, the only difference is that java.exe is a command line tool (so you'll see a command line when you start your application) and javaw.exe simply omits the command line. Both use the same paramaters that can be found here: http://docs.oracle.com/javase/1.5.0/docs/tooldocs/windows/java.html, from this the shorter way to open a Java program will be:
java MainJavaClass.class
or
java -jar JavaProgram.jar
Most commercial programs are packed in jar files so probably you will use the second approach, but also be warned that usually commercial Java programs use a native wrapper so you can simply launch a native application (in Windows .exe), without the need to set anything, so you may need to create a shortcut for it instead of the java.exe program, in the case you really need to call the Java program through the JVM, then what you need to change is the Target field so you include the parameters you need to pass to it like this:
"C:\Program Files\Java\jre7\bin\java.exe -jar JavaProgram.jar"
Another way could be use a batch file to start the program and create a link to it instead.
I've compiled haskell program which uses wxHaskell library, now I would like to know how to make it run on other machines which doesn't have wxHaskell installed. Of course I can see errors and I can copy dlls written in output and copy them to that machine but what is professioal sollution, can I write any installer or something like that?
thanks for help
You will need to fully statically link your executable. How to do this varies from system to system, but in general involves passing the -static flag to GHC, and -optl-static to your linker.
If you use the recent cabalized wxHaskell implementations, it's pretty easy, since almost everything is statically linked.
I use InnoSetup, which is Open Source, and works very well. My script needs at least the following:
AppName=My Wonderful Application
AppVerName=My Wonderful Application 0.1.13
CreateAppDir=yes
DefaultDirName={pf}\MyWonderfulApplication
[Files]
Source: "path\to\your\wxWidgets.dll"
Source: "path\to\msvcrt.dll"
Source: "path\to\your\application.exe"
All of the paths except DefaultDirName are paths on your development machine.
The key items are your wxWidgets DLL (may be multiple DLLs, depending on how you built wxWidgets - I recommend and use the monolithic option, which creates a single DLL, wxmsw28u_gcc_custom.dll) and your application binary.
If you are linking to any other libraries, you will need them as well. Many 3rd party libraries on Windows require msvcrt.dll, which is why I've mentioned it.