I'm working on a classic Sencha project using a M1-pro Macbook Pro. ... Sencha "$#". java(3259,0x30a9d7000) malloc: Heap corruption detected, free list is damaged at 0x600003dcba80
*** Incorrect guard value: 105553168608752
I've have similar issues ever since migrating to the M1 platform. Sencha CMD's included JRE is not compiled for the ARM architecture and even with Rosetta 2, there still seems to be issues with how the included JRE operates in the different architecture. The best workaround I've found is to switch to a JRE compiled for the ARM architecture and that is also compatible with Sencha CMD. Oracle offers an M1 compatible Java SDK but it is the latest version (17) and it won't work with Sencha CMD which needs a JDK in the version 8-11 range. I've found that Bellsoft's M1 versions seem to work the best. You can download it here
I've also had similar experiences, but occasionally Sencha CMD will start.
But I have a possible other solution, or an extra step necessary to have the solution from #aatb to work: for me the db_file Sencha uses to store the Java environment contained references to older versions of CMD or java.
For me a solution was to remove the file: ~/.install4j
Related
...of the Java Runtime (class file version 54.0), this version of the Java Runtime only recognizes class file versions up to 52.0
I have moved from a Windows to an Ubuntu machine and am arranging all the projects. A bit difficult all of it but have got through for all of it with the exception of my CodenameOne project, which is firing this exception when launching the simulator in Netbeans 8.0.2.
The designer is not working either.
I am running JDK 1.8 (OpenJDK)
Can anybody hint me on what could I try next?
In short, OpenJDK8 is not supported by the CN1 simulator because it doesn't include JavaFX. You need to use Oracle's JDK8. OpenJDK11 is, however, supported, as it is able to use JavaFX11 (which is now not part of the JDK).
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
I'm trying to install the mod_xsendfile Apache Module on Windows (7) x64 (using Apache 2.2) -- yes I'm doomed from the get-go, I know :-). Apparently there is :
a) No Win x64 binary for mod_xsendfile, just a Win32 binary from the module's website
b) No Win x64 binary for apxs from ApacheLounge
I've tried the usual LoadModule xsendfile_module modules/mod_xsendfile.so but the semi-obvious error (httpd: Syntax error on line 127 of C:/Apache/conf/httpd.conf: Cannot load C:/Apache/modules/mod_xsendfile.so into
server: The specified module could not be found.) occurs, it's not Win x64 compatible.
The question remains -- how does one build the module for x64, is that even possible ? I have VS and any tools that might be required.
I just wanted to see if this would improve my Rails protected attachment download speed - currently getting quite ghastly speeds for simple images.
Thank you in advance !
I'm the author of mod_xsendfile.
I provide win32 binaries only as a courtesy. I still recommend you build yourself from the source. That way you can be sure the binary isn't tampered with, not even by me :p
There are currently no official Win64 Apache2 (or 2.2) builds from the Apache Foundation. Since I test my builds against the official binaries I cannot be sure the binaries will work once the foundation releases official Win64 binaries. Hence no Win64 builds from me
Building from the source is pretty much straight-forward if you aren't novice to (in the Windows case) Visual Studio. The binaries ZIP and/or my github repo contain project files you may import into your Apache solution. I was told even the free Visual Studio Express should be enough to do working builds. The thing is open source.
Should there be unanticipated portability problems, I welcome patches ;)
As a last resort you can still run the official Win32 apache + mod_xsendfile on a Win64 box.
I was able to load mod_xsendfile in my system.
Here's my setup:
-Windows 7 Ultimate x64
-Apache/2.2.9 (installed via Xampp 1.6.7)
Basically, I just downloaded the module from here:
http://www.apachelounge.com/download/mods/mod_xsendfile-0.9-w32.zip
...extracted it to the "modules" directory of apache, added "LoadModule xsendfile_module modules/mod_xsendfile.so" to httpd.conf, then restarted apache.
After this, I checked the loaded modules using phpinfo(), and mod_xsendfile is already available.
Here are the binaries for both x32 and x64
https://github.com/nmaier/mod_xsendfile
Does Intellij Idea 8.1.x install and run on Mac OSX 10.6 (snow-leopard)?
Are there any special steps needed to get it to work?
Yes, we've verified that it works fine on the Snow Leopard. The new version of Java 1.6 fixes the known problems with menus and crashes which affected IDEA on the previous version after Java Update 4 (promised to be fixed in Java Update 5).
There is no JDK 1.5 on Snow Leopard, so IDEA will use JDK 1.6 despite of the settings in the Info.plist file.
If you'll have any problems, it's recommended to replace the Java application stub with the new version:
overwrite /IntelliJ IDEA.app/Contents/MacOS/idea with
/System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub.
The new application stub will be bundled with the next IDEA builds. Note that with the old stub IDEA will run under 32-bit JVM, while with the new stub it will run under 64-bit JVM.
The question is in the title. Using GCC version 3.4.5 on Windows Vista and a recent version of the Eclipse C/C++ IDE (not sure what version exactly because it's hard to figure out which version is the one for the whole IDE, but I downloaded it two weeks ago so it can't be that old).
This depends on the build system you use, but you can always try adding the "CFLAGS=-std=c99" as a build and/or environment variable the the builder.