How I can get current executable path in Haxe when programm was launched by lime/openfl?
for example:
#if neko
trace('neko >> ${neko.vm.Module.local().name}');
#elseif cpp
trace('cpp >> ${Sys.executablePath()}');
#end
will return:
result for neko target (lime test linux -64 -neko):
neko >>
result for cpp target (lime test linux -64 -cpp):
cpp >> /usr/local/bin/lime
(this example works fine when I launch compiled files "bin/Main" or "neko bin/Main.n" directly, but I need to get this path when programm was launched by lime/openfl too)
Thanks.
There´s no need to handle it differently when targeting Neko since the Sys class is available for all platforms: http://api.haxe.org/Sys.html
class Sys
no package
Available on python, neko, java, macro, cpp, lua, php, cs
Using Sys.executablePath() will return the path to the executable when targeting both Neko and cpp :).
Related
I have a large codebase with Linux dependencies, and I would like to use CMake to compile my code into an executable that can be run on Windows, i.e. I want CMake to produce an ".exe" file or something of that nature.
I have tried using the solution provided on the CMake website: https://cmake.org/cmake/help/v3.4/manual/cmake-toolchains.7.html#cross-compiling
however it has not worked...
Here is my CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(myProject VERSION 1.0 LANGUAGES C CXX)
set(CMAKE_CROSSCOMPILING true)
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_VERSION 10.0)
set(CMAKE_SYSTEM_PROCESSOR arm)
find_package(... *all my required packages* REQUIRED)
include(... *required include files*)
add_executable(${PROJECT_NAME} ...)
target_link_libraries(${PROJECT_NAME} ...)
It compiles and will execute on Linux, however I want it to produce a Windows compatible executable.
You need a mingw-w64 toolchain in Linux to do this, for example on Arch Linux you can get all the necessary mingw-w64-... packages through AUR, including mingw-w64-cmake. These packets should get you going:
mingw-w64-binutils-symlinks
mingw-w64-gcc
mingw-w64-cmake
Install others to fulfill any dependencies of your software.
Then you can just run mingw-w64-cmake instead of cmake using your regular CMakeLists.txt. E.g.:
mkdir build-mingw; cd build-mingw
x86_64-w64-mingw32-cmake ../
make
However typically it is a good idea to use a static build so your executable will work standalone. Here is how I do it:
# STATIC stuff (Windows)
if (${CMAKE_SYSTEM_NAME} MATCHES "Windows")
set(BUILD_FOR_WIN TRUE)
endif()
option(STATIC_BUILD "Build a static binary." ${BUILD_FOR_WIN})
if (STATIC_BUILD)
set(CMAKE_EXE_LINKER_FLAGS "-static")
set(CMAKE_FIND_LIBRARY_SUFFIXES ".a" CONFIG)
set(BUILD_SHARED_LIBS OFF)
endif()
Which creates a variable, STATIC_BUILD, that the user can set, and is defaulted to ON if compiling for Windows.
There is not much more you need to adapt in your CMake files. For example I need to include extra Qt platform plugins when building Qt:
if (STATIC_BUILD AND ${CMAKE_SYSTEM_NAME} MATCHES "Windows")
# include plugins into static build on windows
# (we lack support for static on other platforms right now)
set(QT_PLUGINS SvgIcon WindowsIntegration WindowsVistaStyle)
endif()
The key takeaway here for you is first to get the proper environment on your system.
I've installed Swift lang for Linux (Ubuntu) and it works fine. For example:
print("Hello World")
To run it:
./swift hi.swift
My question is, is it possible to generate a native executable code for it? How?
Listing the executable files in the Swift directory, it has swiftc. It generates a native executable binary by command:
swiftc hi.swift -o hi
./hi
In addition to swiftc, one can also generate native executables by using the Swift build system, which is described at
https://swift.org/getting-started/#using-the-build-system
Using the build system, one can easily build native executables from multiple source files, while swiftc is a convenient way to build an executable from a single source file.
Please note that you also need to install Clang if you want to create native executables with Swift. Clang is not needed to run the swift command interactively or to run a .swift file. Interestingly, installing GCC (including g++) and creating symlink clang++ to g++ does allow swiftrc to build an executable. This also enables swift build to work. At least it is true for very simple programs. However, this is not a "blessed" way. Apple docs at swift.org say that Clang is needed.
I am trying to integrate a Matlab program I wrote into some Fortran code. I tried to follow the example Mathworks provides. But I can't get it to compile because I can't find the header files it requests.
Does anyone know of an example of someone getting it to work on Linux using an Intel compiler. I think that might be part of the problem because Matlab only supports GNU Fortran on Linux.
And I realize this is a simple question, I just don't understand how to do anything in compiling more complicated than including multiple files with defined paths.
Disclaimer: I'm currently using OS X so I can only provide output from OS X but everything should transfer easily over to Linux due to the Unix base. I also don't have the Intel Fortran compiler on OS X (only the C/C++ compiler).
Note: You will need to substitute the paths I use for the correct paths on your system depending on your MATLAB installation directory.
This issue isn't specific to the Intel Compiler, I also receive errors with the GCC Fortran compiler.
$ gfortran fengdemo.F
fengdemo.F:1:0:
#include "fintrf.h"
^
Fatal Error: fintrf.h: No such file or directory
compilation terminated.
You can use the Unix locate command to find files.
$ locate fintrf.h
/Applications/Matlab R2014a.app/extern/include/fintrf.h
In the directory where fengdemo.F is we can then pass the correct directory in using the -I option
-I../../include/
However, this produces linking errors as we haven't specified where the libraries for fintrf.h can be found. We can do this with the -L option (you will need to replace maci64 with the correct option for Linux - I can't remember it off the top of my head but you should be able to see it in the bin directory)
-L../../../bin/maci64/
Now we need to tell it what libraries to use with -leng -lmx and so the completed command is
$ ifort fengdemo.F -I../../include/ -L../../../bin/maci64/ -leng -lmx
and it should compile correctly.
We aren't finished yet though as it won't execute. We need to set up our PATH and DYLD_LIBRARY_PATH environment variables correctly. Specifically we need to add the bin and bin/maci64 directories of our MATLAB installation to PATH
$ export PATH=$PATH:/Applications/Matlab\ R2014a.app/bin/maci64:/Applications/Matlab\ R2014a.app/bin
and the bin/maci64/ and sys/os/maci64/ to DYLD_LIBRARY_PATH
$ export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Applications/Matlab\ R2014a.app/bin/maci64/:/Applications/Matlab\ R2014a.app/sys/os/maci64/
Note: On Linux DYLD_LIBRARY_PATH should be LD_LIBRARY_PATH. Thanks to Vladimir F for correcting me.
Now you can execute the program using
$ ./a.out
When I compiled a program on cygwin like the following
g++ -o helloworld helloworld.cpp
An executable helloworld.exe is created. However, I could not execute the program by using
./helloworld
but instead I need to use
./helloworld.exe
Is there a way to enable the cygwin to recognize helloworld as an executable for the file helloworld.exe
This isn't directly related to g++.
Windows requires executable files (of the kind generated by a compiler, not batch files) to have names with a .exe extension; that's how the OS recognizes them as executables.
Cygwin, as you know, implements a POSIX-like layer on top of Windows. POSIX systems (UNIX, Linux, et al) do not require any special suffix for executable files; the OS recognizes a file as executable based on a "magic number" in the file itself and the executable bit in its directory entry.
To bridge this gap, Cygwin treats the .exe extension separately. Compilers like g++ generate executable files with the .exe suffix, but Cygwin lets you execute a file named helloworld.exe by typing either ./helloworld.exe or ./helloworld. (This even applies to other operations; ls -l helloworld will show you information about helloworld.exe -- assuming there's not also a file named just helloworld.)
In this case, based in information you've provided in the comments, you apparently have two executable files in your current directory, helloworld.exe and helloworld.
I'm not 100% sure what Cygwin will do in this case, but the solution is to delete the helloworld file and make sure that your executables have the required .exe extension. Cygwin compilers will do this for you by default; even if you run
g++ helloworld.cpp -o helloworld
it will generate an executable file named helloworld.exe.
I don't know what you did to create an executable file without the .exe extension. Whatever it was, don't do it again.
I am trying to compile a simple hello world program in Haskell, with Haskell Platform 2011.2.0.1. If I load the code in WinGHCi, and use the GUI to compile, the .exe is created. Then I can run the .exe from Cygwin.
But if I try to compile the code in Cygwin (using ghc --make), linker fails. But again, if I compile from the Windows cmd prompt, then the compile+linker works fine.
Are there any other environment variables I need to import into Cygwin, to make the compile+linker work in it? I have put the following dirs in my Cygwin PATH: 2011.2.0.1/lib/extralibs/bin, 2011.2.0.1/bin (these are the only two valid Haskell related entries that I could see in the Windows environment variables).
I also noticed a couple of invalid items in the Windows environment variables (this looks like a bug in the Haskell installation):
(system var) C/ProgramFiles/Haskell/bin - this dir does not exist because I have installed Haskell in D disk.
(user var) userxxx/ApplicationData/cabal/bin - this dir does not exist.
I tried to file a bug report in HaskellPlatform, but I dont have permission to do it.
Without access to your development environment or a listing of the errors that you're getting, I can only assume that the issue is related to the way that you've set up your PATH.
GHC on Windows comes bundled with its own gcc compiler (for C code) and ld linker. If you've installed Cygwin, you've probably also installed the MinGW toolchain, which comes with its own version of gcc and ld. Then, you've probably made your PATH variable list /usr/bin before the path to the Haskell Platform binary directories, which makes ghc find the MinGW linker and C compiler before it finds the versions that were bundled with GHC.
You need to make sure that the HP directories are listed before the Cygwin directories. It should not be like this:
$ echo $PATH
/bin:/usr/bin:.../2011.2.0.1/bin
Instead, it should be like this:
$ echo $PATH
.../2011.2.0.1/bin:/bin:/usr/bin
This is only a guess at what the issue might be, and you should provide more details for a better diagnosis.