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).
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.
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 want to create Perl scripts that run on older OS X machines as well as on current versions. Is there a list or a resource where I can find out which Perl versions were distributed with older Mac OS X Versions (10.0 to 10.6)?
I'm sure there is some online resource to find this, probably at Apple Development Connection
However I have three machines to hand which show me that /usr/bin/perl versions are:
5.8.6 on 10.4 (Tiger)
5.8.8 on 10.5 (Leopard)
5.10.0 on 10.6 (Snow Leopard)
In all cases these are thread enabled.
Starting from Snow Leopard, multiple versions of perl are supported under the hood and it also comes with Perl 5.8.9 which you can switch to like so:
defaults write com.apple.versioner.perl Version 5.8.9
Also note that 5.10.0 on Snow Leopard is 64-bit. You can switch to 32-bit by using following:
defaults write com.apple.versioner.perl Prefer-32-Bit -bool yes
/I3az/
Update:
A full list of Perl source code that Apple has compiled with Mac OS X can be found on their Perl opensource page.
Working out what the packaging version numbers mean and how they refer to each version of Mac OS X may take some effort. However each package does show which Perl was compiled with the options, patches & extra modules Apple applied to it.
See Perl and Mac OS X versions for my best stab at working all this out.
is there any gui tools like gnome system monitor in solaris for monitoring processes? or is it possible to get the gnome system monitor binary pkg for solaris os ?
You don't specify which version of Solaris - recent ones include gnome-system-monitor already.
Additional gnome software for older Solaris versions may be available from various projects that make open source software packages available for Solaris, such as SunFreeware, Blastwave, and OpenCSW
The CDE desktop included in Solaris 2.6 through Solaris 10 also includes a couple of simpler process monitoring tools - sdtprocess and sdtperfmeter.
If you dont mind me asking what is the need for a gui?
the command top will give you everything you need but in a terminal?!?
anyway /usr/dt/bin/sdtperfmeter is on older releases but this WONT give you processes
gnome-system-monitor should be installed on newer releases, and this WILL give you processes.
If the gnome-system-monitor command doesn't work top will.
How about GKrellm? That is popular under the Gnome suite running on Linux.
How compatible is code written under Solaris with Open Solaris ? I would be interested specifically in some kernel modules .
I think it is hard to quantify software compatibility, but I'd say code written for Solaris is quite forward compatible with OpenSolaris kernel. OpenSolaris source code evolves into what will be Solaris 11, and Sun's commitment to backwards compatibility is quite a fact.
Kernel modules written for Solaris should function in OpenSolaris following a simple recompile providing you are using the exposed kernel APIs that are compatible between the releases that you are using in Solaris and OpenSolaris.
There is a huge amount of work in Sun to ensure that programs written using publicly exposed interfaces are compatible. There is a listed 'Exposure/Stability' entry at the bottom of manual pages for most APIs that state in defined terms how someone can use it.
Kernel modules in particular will be very compatible between Solaris and OpenSolaris. OpenSolaris (via Project Indiana) is evolving the user-space components more heavily, including the installer and packages.
This is with regard to core OS daemons only and not kernel modules, but I've had success compiling OpenSolaris components from source and using the resulting binaries on commercial Solaris just fine. It's obviously easier with a Makefile but I did one manually.
I tried this with a small handful of binaries that I needed to add debugging output to and compiled them directly on the commercial Solaris system using gcc without issue. As mentioned earlier YMMV based on what app/module it is.