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.
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 am just started exploring the Solaris kernel. I am studying the Solaris kernel modules. During my study I got following question, Is it possible to embed two kernel modules (e.g Solaris 11 and Solaris 11.4 kernel modules) in single package? This scenario is doable in Linux but not sure it is possible in Solaris.
It is possible to embed two modules (say /kernel/misc/foo and /kernel/drv/bar) in the same Solaris IPS package, but not two versions of the same module for different OS releases (such as /kernel/drv/bar for 11.3 and /kernel/drv/bar for 11.4). That problem is usually solved by making two versions of the package - one for the older release and one for the newer release, during the transition period (such as right now, since Solaris 11.4 just came out, so not everyone has upgraded from 11.3 yet - Solaris 11.0 through 11.2 are no longer supported, so you shouldn't need to build modules for them).
My company is using an old CentOS6 and they wont update it before months (years?). This is totally out of my control and it obviously makes using up to date software a nightmare.
I would like to use Visual Studio Code as a C++ IDE but its intellisense plugin is running with glibc >=2.14 and Centos6 comes with glibc 2.12.
It also needed some more dependencies I managed to recompile and load with LD_LIBRARY_PATH. I tried compiling a new glibc and load it as well but it segfault, as expected.
I used the compiled version of VSCode from the official website.
I tried compiling it myself but it requires to download many files and my virtual machine does not have Internet, I can only transfer files through ftp. I created a local yarn repository, compiled all appropriate version of Yarn, NodeJS but a compiled binary is trying to download electron and I have no idea where to put the file to trick him into thinking it's downloaded already (assuming I could).
There are standalone solutions to run software on old distribution, like AppImage but VSCode is not part of their apps.
Would you have any idea on how to run VSCode on Centos6? Did you ever try to compile VSCode without and Internet Connection?
Currently the only viable solution I see would be to create an AppImage at home.
To run VS Code Server on CentOS 6, I followed the "glibc and libstdc ++ on RHEL / CentOS 6 update" article from here.
Perhaps this option will help you.
I am running a web server based on CentOS 5.8 and I need to upgrade my version of bind to make it PCI compliant. I'm currently running bind 9.3.6 and I need to have bind 9.9.8 or higher. I've tried yum update bind but apparently I already have the latest version according to yum. I did some Googling and I found an RPM file bind-9.10.2-1.el5.i686.rpm which looks like it would work but i don't know if it should try installing it or not. I think I would need bind-devel and bind-libs which I can get from the same site. Am I better off compiling from source? I know CentOS 5 is old but I'm trying to avoid reinstalling the whole server.
Installing binary rpm's from later versions of CentOS is unlikely to work: there are many changes since CentOS5.
Rebuilding a src.rpm locally is one way to see what issues there are.
Meanwhile, upgrading to CentOS6 (at least: CentOS7 uses systemd which takes some study) is often not a whole lot more effort than retrofitting something like bind, and will have other efficiencies. YMMV, everyone's does.
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!