Trying investigate how to create "Hello world" on different languages via HaxeDevelop. I'm newbie and may be inacurate at terminology.
1) C# project. Pressing F8 gives me error:
haxe -cp src -cs D:/Programs/Projects/CsTestHaxe/bin/ -main Main
Unix.Unix_error(8, "mkdir", "D:/Programs/Projects/CsTestHaxe/bin/")
Build halted with errors (haxe.exe).
Via googling pretty much outdated info at least found solution:
haxe -main Main -cs out
And it works but ouput go to "src" location which is bad. Next googling led me to "Custom build" and using .hxml with pre-build command at project settings.
But why default template/settings not works for such simple thing as "Hello world" (used cs.system.Console)?
How default build may be fixed / probably I've installed or setup something wrong via HaxeDevelop installation?
2) C++ project. Pressing F8 gives me error:
Warning: Could not find environment variables for Visual Studio
Missing HXCPP_VARS
Error: Could not automatically setup MSVC
Error: Build failed
Build halted with errors (haxe.exe).
Using command line (similar to C# above) I can exucute C++ sources, but cant compile it.
Installed Visual Studio Community 2017. Nothing changed, same error. VS provide different own parts for installation. Should I install any specific?
Found also many threads about OpenFL workaround for C++ compilation. But I needn't OpenFL and want to use default Haxe API and tools.
Also OpenFL and C++ always mentioned with Lime. Do I need it too? Installed Lime via command line. But seems nothing changed.
3) Am I right that HaxeDevelop not yet support HashLink?
And if possible couple words about why HashLink appeared if there is Neko affiliated with Haxe?
As a result here an additional question: is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?
1) C# project. Pressing F8 gives me error.
This appears to be a known Haxe issue. Since it's been fixed on the dev branch, you could try a nightly build from build.haxe.org. Alternatively, you could also try manually creating the bin directory, since that seems to be what the error is about.
2) C++ project. Pressing F8 gives me error:
The latest Haxelib release of hxcpp (3.4.64) does not support Visual Studio 2017 yet. You could use a development version by installing hxcpp from GitHub, since again, it should be fixed there:
haxelib git hxcpp https://github.com/HaxeFoundation/hxcpp
The alternative is to downgrade Visual Studio.
Also OpenFL and C++ always mentioned with Lime. Do I need it too?
Yes, if you want to use OpenFL, you also need Lime, as OpenFL depends on it.
3) Am I right that HaxeDevelop not yet support HashLink?
Actually, a HashLink project template was added. But to follow the general theme of this answer, it seems it hasn't made it into an official relase yet. You can get a nightly build from here.
And if possible couple words about why HashLink appeared if there is Neko affilated with Haxe?
There is a two-part blog series on haxe.org by HashLink's author: part 1, part 2. The first part has a paragraph talking about this exact topic. Here's an excerpt:
First, let me explain the reasons for writing another virtual machine in replacement of Neko.
[...]
Back then, the Neko virtual machine was not especially designed to run Haxe and suffered from some limitations, the main one being performance.
[...]
And to your final question:
is it right that Haxe during compilation to target platform only "convert" .hx source to target one and then using third party (target platform) compile?
That is true for some targets, but it depends. For C++, C# and Java, Haxe indeeds generates source code for the target language and then invokes the target-native compiler after doing its own compilation (this step is usually called "native compilation").
However, some targets produce byte code directly (SWF and Neko), so there is no native compilation step there. Other target languages are interpreted (JS, PHP, Python and Lua), so there's no native compilation step there either. For HL it actually depends, there is HL/Jit (byte code) and HL/C, which is compiled to native C code.
You can find a comprehensive list of Haxe targets an their characteristics here.
Phew, that was a lot of questions in one. ;)
Related
Due to:
extensive usage of code auto-generation (notably for the .isa instruction and decoder sublanguage)
scons symlinking sources into the build tree, and in particular symlinking src/arch/ARCH to src/ARCH
it becomes very hard to setup Eclipse to work well with gem5.
Has anyone managed to achieve a good setup? Especially interested in Linux hosts.
I have achieved a very good setup with the following horrendous hack: define the Eclipse project inside the build/ARM directory itself!
This is done by creating a "New makefile project with existing code" in the build directory. You will also want to fix the C++ standard library as mentioned at: How to solve "Unresolved inclusion: <iostream>" in a C++ file in Eclipse CDT?
This works amazingly because the way the gem5 build system works as of May 2020, the build/ARM directory contains exactly the final compilation tree, including all the source symlinks and autogenerated code,.
This setup is not perfect because there is still some C++ stuff in build/ outside of ARM, e.g. ext, but 99% of the time we don't care about those, and I can perfectly navigate key autogenerated code such as instructions and decoder.
I then just build via the command line normally with scons.
Humongous autogenerated files like exec-ns.cc.inc turn on Eclipse's large file limited mode. Notably, if you want to jump to a definition, Ctrl + click does not work for me, so I just copy the symbol of interest and Ctrl + Shift + T to go to its definition.
I don't usually bother to try GDB step debug gem5 through Eclipse and use it mostly for code navigation, since GDB Dashboard tends to work well enough for me, and I often need to do new log collection runs and I sometimes use reverse debugging when things get serious.
But I have tested step debugging through Eclipse, and it did work normally (no reason not to I guess), you just have to set it up in exactly the same was as for any other C++ application with a Makefile, i.e. basically tell eclipse the Binary name and the desired CLI on the debug configurations.
You have of course as usual to choose between a gem5.debug debug build or a gem5.opt build, where the .debug build is about 10-20x slower but gives greater debug visibility. In general, if the time to reach the point of interest in a debug build starts to annoy you however, what you tend to really want is to do use reverse debugging.
This is also mentioned at: https://cirosantilli.com/linux-kernel-module-cheat/#gem5-eclipse-configuration
Tested in Eclipse 2020-03.
I have compiled Lua 5.3 as a 32 bit c++ DLL and exe. The DLL contains all the lua code except for lua.cpp and luac.cpp. The exe compiles lua.cpp and uses the DLL to run the lua interpreter. This works fine when running on its own from the command line. I wish to be able to run from the IDE using this DLL and exe.
If I replace /ZeroBraneStudio/bin/lua53.dll and lua53.exe with my own versions, I can run scripts (clicking the two green arrows). However, debugging does not work, giving the following error:
The procedure entry point luaL_addlstring could not be located in the dynamic link library lua53.dll.
I can see that this is happening because the debugger is making use of luasocket. \ZeroBraneStudio\bin\clibs53\socket\core.dll is dependent on lua53.dll, and is expecting it to contain lua compiled as c.
So, what is the correct solution to this - is it to compile luasocket as c++ as well?
(And, if so, does anybody have instructions/guidance for doing so? I have been unable to find anything on this.)
Thanks.
I'm not sure how exactly the DLL was compiled, but the error message likely indicates that the luaL_addlstring and other functions are not exported by it. If the symbols are exported correctly, you should be able to load luasocket and get the debugging working. See this thread for the related discussion.
Also, you don't need to replace lua53 library and executable, as you can configure the IDE to use your own copy of it using path.lua53 configuration setting as described in the documentation.
Okay, I was able to get it working. The solution was to compile luasocket as c++. I won't give full instructions on how to do this here, but some points to hopefully help anybody else with the same issue:
Got luasocket from here: https://github.com/diegonehab/luasocket
Renamed all *.c files to *.cpp
Renamed Lua52.props to Lua.props (I am using lua 5.3 but seems like it is compatible?)
Placed lua headers and lib in appropriate folders
Opened solution in Visual Studio 2012
Fixed up minor issues with project files, like the renaming of the files.
Added 'extern "C"' to declaration of luaopen_socket_core and luaopen_mime_core functions (necessary for lua to be able to load libraries).
Built solution
Copied new dlls into clibs53/socket and clibs53/mime folders.
I used Dependency Walker to help with this. If anybody wants further details in the future please leave a comment.
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.
i am currently trying to implement a "third party framework" (FeedbackReporter.Framework) into my preferencepane.
Unfortunately I am getting the following error all the time when trying to launch my preference pane:
16.05.10 23:13:30 System Preferences[32645] dlopen_preflight
failed with
dlopen_preflight(/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane):
Library not loaded:
#executable_path/../Frameworks/FeedbackReporter.framework/Versions/A/FeedbackReporter
Referenced from:
/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane
Reason: image not found for
/Users/me/Library/PreferencePanes/myPane.prefPane
As far as I read so far, this problem is probably caused because my prefPane is no actual app, but a "plugin" of "System Settings.app" and thus #executable_path resolves to a path within the bundle of this app, instead of the bundle of my prefpane.
But I don't really picked up howto fix this problem. I guess it must be fairly easy since it should be a usual case that people use non-apple-frameworks in PreferencePanes.
Thanks for your hints!
--
Short Update:
As far as I understood tons of docs I read so far, there might be a setting which has to be done in the third-party framework. Obviously the "install path" has to be set to "loader_path" instead to "executable_path" in order to work in a preferencepane.
But since I am using a precompiled framework (FeedbackReporter.framework) this is probably a setting which the author has to change?! and even if i could compile the framework myself, i had no idea where to change this install_path in Xcode.
If you cannot wait for the next release just download the source, change it in
FeedbackReporter.xcodeproj/project.pbxproj
and then open and compile the framework yourself.
Actually, you can change it yourself without recompiling the third party framework. You can use install_name_tool to change where a MachO binary will look for shared object libraries. First use otool -L <binary file for your plugin> to get the paths of where it expects its libraries to be, then use install_name_tool -change ... to change the paths in that file. Repeat for any bundled frameworks.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
using frameworks in a command line tool
Hey,
I've written a command line 'foundation tool' that uses the RegexKit.framework extensively. Everything works when run in Xcode but if I compile the release build and try to run it in Terminal I get the following error:
dyld: Library not loaded: #executable_path/../Frameworks/RegexKit.framework/Versions/A/RegexKit
Closer inspection reveals that the RegexKit.framework bundle is sat in the same directory as my executable file... I've done some research and I'm thinking that as command line tools don't use application bundles there's no where for Xcode to copy the framework to. So I'm guessing that I need to compile the framework as a static library and include it in my code... am I right? If so, how do I go about doing this? Is there anything I can do in Terminal to point to the framework externally?
Any help would be very greatly received, I've been banging my head against this for a few days now!
Thanks in advance,
Tom
So... What I did in the end was to recompile the framework with a different Installation Directory (in the Deployment section, under the Build tab in the Target's Info) - I set it to just #executable_path.
I then compiled the framework and replaced the one in my Utilitie's project, I also changed the Copy Files build phase to copy the framework to "Executables" rather than Frameworks.
The good news is that this fixes my original problem - but obviously the framework has to be in the same directory as the executable.
So this got me unstuck but I'd still love to know how to compile RegexKit.framework statically!
You shouldn't be installing the framework in the Executable folder of your bundle. It should be in the Frameworks folder. You need a Copy Files phase in your project that copies the framework and you need to set the Destination to "Frameworks". "Copy only when installing" should be unchecked.
When testing this, you should make sure you perform a clean build. I typically delete the build folder rather than using Xcode's Clean menu option since it's quicker and more comprehensive.
Also: you cannot statically link to a framework. If you want to statically link to something, it needs to be a static library so in this case, you'd need to hack about with RegexKit. Bear in mind that static libraries cannot contain resources, whereas Frameworks, being bundles, can.