I'm trying to build JXcore on Windows 7 (64 bits).
In fact I have two identical virtual machines, but when i run vcbuild.bat it fails for one of them. I get the following error:
C:\jxcore\vcbuild.bat
File "configure", line 339
'''
^
SyntaxError: Missing parentheses in call to 'print'
Failed to create vc project files.
On the second machine I don't have this problem. As far as I remember, I've created them both identical. Where is the problem then?
Are those two VMs really equal? I can bet, that the one which fails, has Python 3.X installed, while the JXcore docs are stating about Python 2.6 or 2.7.
Nevertheless, we've just made an update, and the error that you've posted should not show up any more. Instead you should see something like this:
C:\jxcore>vcbuild.bat
You need Python 2.6 or 2.7 for the script to run. Currently installed version: 3.4.3
I hope that solves your problem. Thanks for using JXcore!
Related
I am trying to use the latest version of the appImage-builder because appimages of my application built with the old version of appImage-builder do not run on ubuntu 22.04 anymore. So I got the order to try and see if it works with the new appImage-builder.
Currently (June 2022), only versions below 1.0 which are based on ubuntu 18.04 are available on docker (which we previously used to build our appimage).
The newer versions are available via github (https://github.com/AppImageCrafters/appimage-builder/releases).
However, I seem to be unable to execute:
appimage-builder --generate
or
appimage-builder --recipe AppImageBuilder.yml
Is there any documentation available on how to correctly use the .appimage version of appImage-builder? All I could find in https://appimage-builder.readthedocs.io/en/latest/ seems to refer to the docker version or a manually built version of appImage-builder.
Depending on the error message you get, there could be a couple of issues at play here.
If you got an error related to FUSE, then you need to install the libfuse2 package with apt install libfuse2. AppImages rely on libfuse2, but Ubuntu has stopped including it since 22.04, in favor of libfuse3.
If you get an error related to "file not found", then it could be that you do not have AppImageLauncher installed. Sadly, with type 2 AppImages the design decision was taken to modify the ELF header of the executable with 3 magic bytes at offset 8 of the executable. This means that Linux linkers will not run the file. AppImageLauncher actually copies the file to a temporary directory and zeroes out the magic number in order to be able to execute it.
A good starting point for debugging issues like this is to run the strace command, which will let you see which system call likely cause the error. Keep in mind that if you try to execute a file and you get File not found, it might mean that the linker specified by the file can not be found on the system or the ELF header is not valid. You can also run the executable by using the linker directly, which might give you more clues. For example with: /lib64/ld-linux-x86-64.so.2 <NAME-OF-YOUR-EXECUTABLE>.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
I'm trying to deploy my site using Fabric and Mercurial. In the Windows command line, running hg push works perfectly with no problems.
But when I try writing
local("hg push")
in a fabfile and running it, I get the error:
'"hg push"' is not recognized as an internal or external command, operable program or batch file.
Googling gave me an idea that it might be a problem with the PATH variable in Python subprocesses, for example here: Why would an "command not recognized" error occur only when a window is populated?.
Can you help me out? Is the bug in Fabric or in my own code?
Thanks.
As Chris R mentions, we don't do a ton of Windows support as none of the core devs are Windows users; we have to rely on reports and suggestions from our more savvy Windows users.
It sounds like this could be related to this recently fixed, but not released, bug -- it will be in Fabric 1.0.2 which should be out soon. If you're feeling brave, you can test it out now via:
pip install -e git+git://github.com/bitprophet/fabric#1.0#egg=Fabric
If you then do fab -V, it should say it's 1.0.2a -- if so, running your fabfile may work better. Please let us know if you do this!
It sounds like the you need to add Mercurial to the Fabric process's PATH.
Maybe something like:
fabric.context_managers.path(<path to your hg.exe>)
run('hg push')
See the docs for the path context manager. It wasn't clear if path applies to local commands, but run commands are explicitly referenced.
Neither of the fixes provided worked, but changing
local("hg push")
to
os.system("hg push")
solved the problem.
I'm trying to run ohai.bat os_version within cygwin on Windows Server 2003 R2, and it returns an empty array as output. If I instead run ohai os_version in cmd.exe, then it correctly returns:
[
"5.2.3790"
]
Given that ohai.bat os_version works on another one of my virtual machines, I'm inclined to believe that this is an environment misconfiguration of some form. Does anyone have any ideas on what to check?
It turns out that the problem is caused by systemu not properly quoting directory names. This commit fixes the problem, but is not currently available in any released gem. It will be in version 2.0.0 of systemu. To fix it in your own project for now, you'll need to clone systemu off github and build the gem yourself.
I'm trying to work through the quick start tutorial of the Zend Framework version 1.8.2, but I'm getting an error when running this code:
zf.sh create project quickstart
error: expecting `'{'' in /Users/andrew/Sites/_library/ZendFramework-1.8.2/library/Zend/Tool/Framework/Client/Console.php on line 63
I'm doing this on Mac OS X 10.4. Is there an error in Zend Tool? or am I doing something wrong? Or is my environment not set up correctly to run this script?
I tried this on my other computer and got
-bash: zf.sh: command not found
I think this one is a separate problem, but not sure what to do
to the second problem:
$ chmod +x zf.sh
or place it to /usr/bin (or where the other executables lives, don't know where it is in OS X)
or use
$ sh ./zf.sh
first problem:
which PHP version do you use? The problem exists maybe at multi interface implementation.
you can still manually create the folder structure that Zend_Tool does, the quickstart guide does give examples of the naming conventions and there are numerous other examples. in order to better understand the framework, doing this manually can be good since your forced to think about the files your creating and how they are used.