I am having trouble with Gwan, I have used is successfully without hiccup on several machines but having trouble with my current machine CentOS 6.3 64bit Final, gwan version 3.12.26, glibc version 2.12 (stable) from gwan.
Whenever I try and start gwan ./gwan
It returns back with
Linking loan.c: failed to map segment from shared object: Operation not permitted
I have full root access, have made sure that all .so shared files are executable, and ensured that SELinux was OFF.
Anything you all can shed some light on would be great
There are stability issues on version 3.12.26 due to GLIBC wrappers and direct system calls. The issues are different on different OS/GLIBC that's why it's working on some machines and not working on others.
I will suggest to use 3.3 (If you have it) for now until version 4 is released.
Richard Heath, give the link to download 3.3 version! Why all advices about G-WAN so uninformative? It's all like bla bla bla. I explore the whole gwan.com website. Only link to download latest version!
Related
We’ve been trying to get SikuliX 2.0.5 to run on a RHEL 8 system, and not having much luck.
We went through the instructions on this webpage:
https://sikulix-2014.readthedocs.io/en/latest/newslinux.html#newslinux
We started on RHEL 7, but the OpenCV shared library required a newer version of GLIBC than is standard on RHEL 7 (version ‘GLIBC_2.27’ not found (required by ~/.Sikulix/SikuliLibs/libopencv_java430.so)), so we moved up to RHEL 8. We had to build OpenCV (v4.3.0) from source because we could not find a java companion package for RHEL 8, which required quite a few other dependencies, but in the end we got it built with most options enabled, and installed as root on the system. We also got Tesseract installed via a package, as well as xdotool and wmctrl.
We are setting LD_LIBRARY_PATH to ensure that the OpenCV libs are picked up, and when we run with the “-v -c” options to the IDE, there are no obvious problems reported. It seems to believe it is moving the mouse, though we can see that it is not, and when we try to capture a screenshot, the “canvas” from which to capture is either uninitialized/garbage frame buffer memory, or a totally black screen. On rare occasions we have seen the actual desktop, but most times we do not.
Originally the system had 2 monitors, but was subsequently reconfigured to a single display system. We were originally running remotely over NoMachine, but have also tried running locally and observed no difference in behavior.
Any pointers or suggestions would be most welcome. Given that no error messages are being reported, we are out of ideas for how to proceed in debugging the problem. It appears that more native support is provided for Debian-based systems, but we’re attempting to validate a product which only advertises support for RHEL systems, so we’d prefer to get it working in this environment if at all possible.
I've been looking for information about this, but I don't find anything. I think there's no version available at Oracle site for installing Weblogic 12.2.1.X on Apple M1 devices, but maybe it's possible to do it using Rosetta 2.
Has somebody tried it? I cannot because I don't have an M1 device yet, but I'm wondering because I still develop soft that runs on Weblogic.
I could, but i had to add an argument -ignoreSysPrereqs (for example java -jar fmw_12.2.1.3.0_wls.jar -ignoreSysPrereqs), because throwed me a error
The error:
Checking if CPU speed is above 300 MHz. Actual unknown. Failed <<<<
I used this documentation:
https://community.oracle.com/tech/apps-infra/discussion/3888969/veridata-installation-checking-cpu-speed-failed
I currently use different versions (10.3.6,..)
I just copy the folder installed in an old mac with intel, an then they work 99%, was necessary fix the folders resource like java.
But just realize have an issue on ServiceConnector, for remote calls ..
Put succinctly I need a base for my system, since it was built on macOS Darwin seems like the logical choice as it will require the least porting effort. I know you can download up to Darwin 8.0.1 from Apple, and the full source tree is available for up to 10.0, however v8 is too old and lacks many standard modern features (i.e. a password system that doesn't restrict the root user to 10 characters, or support for the case-sensitive version of HFS+). I've tried building Darwin 9/10/11/12 from source using darwinbuild, but it always fails for various server-side reasons.
There has to be some way to create the equivalent of a vanilla Darwin 16 image. Perhaps taking an existing copy of macOS and stripping away all the closed-source stuff? Building the source that Apple provides at Apple Open Source Repository and substituting the rest of the packages required for the OS to function with source from another BSD distro? Taking an existing copy of FreeBSD and substituting the kernel with XNU? There has to be some way. Any ideas or thoughts on the ideas I suggested are welcome. Thanks.
The last xnu build instructions are for El Capitan (Darwin 15) but you might be able to follow them for Sierra (Darwin 16). The latest source available at time of writing is for 10.12.4, which isn't overly out of date.
This gets you most of the kernel of shipping macOS. It doesn't get you the driver stack - especially the SATA/AHCI stack is not open source, which could be a problem. (One of these days I'll get around to publishing our full virtio driver stack including virtio-blk and virtio-scsi drivers, with which you should be able to run without SATA in Qemu/KVM at least.)
I have no idea about getting a useful userland going - macOS/OSX uses launchd as its "init" process, and the last published source code for that is some years old. I don't know if it will need some tweaking to get it working on newer kernels.
JProfiler agent seems to require glibc 2.7, but Centos has glibc 2.5. Has anyone successfully compiled the jprofiler agent for glibc 2.5 or did previous version of JProfiler create agents with 2.5?
Actul error is
Error occurred during initialization of VM
Could not find agent library /opt/jprofiler/bin/linux-x64/libjprofilerti.so in absolute path, with error: /lib64/libc.so.6: version `GLIBC_2.7' not found (required by /opt/jprofiler/bin/linux-x64/libjprofilerti.so)
The problem is that JProfiler you are using has been built on a system with glibc-2.7 (or later).
In general, UNIX systems support backwards compatibility (code compiled on an older system continues to work on a newer one), but not forward compatibility (you can't expect code built on a newer system to work on an older one).
Your choices are: upgrade your version of glibc, or obtain a different build of JProfiler (that was built on glibc-2.5 based system or older).
That's actually a regression in 7.0.1, an easy workaround is to use 7.0:
http://download.ej-technologies.com/jprofiler/jprofiler_linux_7_0.tar.gz
We'll fix this dependency problem shortly (my company develops JProfiler). Thanks for letting us know.
I have a very strange issue that I'm hoping someone can help me with. I have various installations of Eclipse on my development machine at work. The one I primarily use is Weblogic WorkSpace Studio 10.2. This installation, along with a few Pulse installations I have set up works fine when I'm logged into my computer physically.
However, when I try to log into the computer using Microsoft's Remote Desktop Connection utility I get an error stating: "Could not create Java virtual machine." and then I get the lovely Eclipse error box which I personally can gather almost nothing from.
Even if you don't have the solution, any help would be greatly appreciated.
Justin
What ended up working for me was the memory settings for the JVM. Apparently the remote desktop connection, or some other setting in Windows, blocks off a fairly large amount of space. By reducing the heap size allocation for the JVM during Eclipse and server start-up I was able to get this working. As a side note, I had PLENTY of space that windows could have used, so I don't think blankly adding more memory would necessarily solve the issue. If you find another solution, please let me know.
• We came across an issue when user RDC’s to a remote system where the OS is Windows 10 and has a running Eclipse instance, the Eclipse instance terminates
• Eclipse is one of the IDE’s for Java
• The issue is because of Windows 10 Exploit protection
• Pre-requisite: You will need Administrative permissions for executing the below
• Navigate to Settings -> Update & Security -> Windows Security -> App & Browser Control -> Exploit Protection Settings
• Add the program to exclude as below
P.s. As of Window 10 1909 MS security advisory mentions we can disable some exploit protections by default.
Perhaps it is permission related. take a look at similar issue that symantec has:
http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/8ea1593f1d1fcee68025759a003d8403?OpenDocument
Try to see if you have same patches installed that causes the security issue. Also refer to application log to see if there is a more specific error. Good luck :)
I think issue happens due to Windows, not Eclipse nor JVM. There is still open Bug report on the Eclipse side and one of the comments state that Microsoft is working on the issue.
I have tried Windows Remote Desktop-ing into my dev machine at work (which had only one version of eclipse installed on it). I had no troubles.
Is it possible that your problems stem from multiple versions of eclipse running at the same time?
Also, have you tried a fresh install of eclipse on your dev machine?
If the above two suggestions don't work, then the only thing that I can think of is what Mohammad said: you might need to check your permissions.
I would check the system log if I were you: Start > run > eventvwr
The first thing to look at is the .log file which is in your eclipse's metadata folder (found in your workspace at $WORKSPACE_ROOT/.metadata/.log). If you post the stack trace that it generates upon initialization, we can give a definitive answer.
I am now experiencing this in Eclipse (the Oxygen release and Java 1.8.0_181). I previously had the same problem with another Java-based program (Oxygen XML/XSL editor - the product name is coincidentally the same as the Eclipse version). Last year the Oxygen support team answered that it may be a known problem in Java.
Even without seeing a crash report, considering your sequence of
events, this seems like a known common cause of crash for the Java
runtime. Keeping Oxygen/Java running for a long time, until the screen
or video card enters sleep then connecting/disconnecting
screens/projectors or connecting/disconnecting RDP can trigger a crash
in the Java runtime. We keep updating the Java runtime (JRE) with each
new version of Oxygen, but so far the issue has not been resolved in
newer versions of the JRE.
e.g. Java VM logged issue:
https://bugs.openjdk.java.net/browse/JDK-8153389