as part of my work I need to fetch kernel headers for all kernel versions for sles.
We use them to compile Kernel objects for our product to run on sles distro.
I have a customer with a specific sles 11 version and I cannot find the relevant Kernel Headers.
I have an account with SUSE and I am searching manually for a specific kernel version headers (RPM files)
The specific kernel version I am searching headers for is sles 11 sp4 3.0.101-108.120.1.x86_64
Unfortunately when I look in https://scc.suse.com/packages I can only see sles sp12 and up
Can anyone please advise as to where can I find the headers for that specific version?
Thanks!
Check out https://scc.suse.com/patches and search for the keyword „slessp4-kernel-source-14630“.
It should provide you the download links of all kernel-related packages for the version you‘re searching. My mobile browser showed all download buttons grayed out, so unfortunately I can‘t tell you how to proceed from there.
You probably need to login first. Worst case would be that you’d need a subscription, because SLES 11 SP4 is out of general supports and requires LTSS.
Related
I have written a module that gets distributed as a .deb file and rebuilt with kernel updates using DKMS. What I would like is to be able to restrict the system from upgrading the kernel beyond what the module can be compatible with. For example, the module should be rebuilt for any kernel upgrade up to 4.19.1. Ideally, this would be built into .deb file but a second solution would just be restricting the system from installing kernels beyond a certain version. a third option would be presenting the user with a warning that the module won't work with the kernel version being installed.
In the past the driver was installed manually and had to be rebuilt with each kernel update which the user was unaware of. The source file header checked the kernel version for compatibility and wouldn't build if it was outside the allowed kernel range.
My question is about whether if it would be possible to run a compiled perl 5.28.0 from source (with GCC 4.8.5 on CentOS 7) to be able to be used on RHEL 5.5 (Tikanga) where GCC version is lower and so would be the other libs like libc, glibc, etc.
Our production environment is running very old perl version (5.8.8) and due to security concerns, it is under heavy lock down, i.e. most of our servers lack make, gcc and related tools and there is no root access available to anyone
I was wondering if it would be possible to compile perl from source i.e. latest 5.28.0 with GCC 4.8.5 AND try to use this compiled version on our production servers (with GCC 4.8.2).
This will save me tonnes of headaches with slow bureaucracy and I can get going with my project with the new tools.
Have not been able to find any discussion or hint about this subject. Can anyone shed some light?
Thank you in advance.
Update after 2 days:
As it seems Perl 5.28 compiled on RHEL7 does not work on RHEL5.5. You will have to compile it on RHEL5.5 and make it relocatable for further usage on any server.
So I Downloaded the RHEL 5.5 and CentOS5.5 ISOs and ran into bootable iso related issues.
Couldn't make a suitable bootable disk for both rhel 5.5 and centos5.5.
rhel5.5 iso was a single dvd image and upon doing file rhel5.5.iso on command prompt, it showed bootable. tried unebootin, rufous iso creator, dd command and created ISOs and tried all of them one by one, but couldn't get it to show boot menu. tried FAT, NTFS FS while making boot disk. Stuck here now.
Centos5.5 iso came in 8 pieces of 600mb files. Had to create a single iso image out of it and found some online procedure to do it and made one ISO file. Got boot menu and looked like it worked. But then it got hung up on doing some sort of source media check test and couldn't proceed further. Found a fix related article that you imprint md5sum on iso and it should work but it didn't.
Just now found something on grokbase and it mentions a new technique, that could take me forward from the point of failure mentioned in point no.3 above.
Edit: static compilation bypasses the problems you are cautious about. You need to figure out whether the result is suitable for your intended purposes.
Otherwise you contend with traditional compilation like you had planned. If the libc is too different, it won't work. You could certainly just go ahead and try, then you'll know for certain.
The real solution is to set up a copy of your production environment (can be in a virtual machine) and compile stuff there.
You could try PerlApp + ActivePerl from ActiveState.com (maybe a part of PDK, Perl Development Kit). I've used it for many years. It compiles perl source and include modules (compiled modules also) into a .exe-program file on Windows and a binary executable file on Linux. There is a payed version and a free/demo version. The payed version allows for cross-compilation and more versions of Perl if I remember correctly.
You might run into trouble with differing versions of glibc/libc on dev vs prod computer, so try to use PerlApp on a CentOS 5.5 Linux (free) for compilation. CentOS5.5 resembles RHEL5.5 enough for most projects. Good luck.
Try perlbrew (is an admin-free perl installation management tool)
I could find that vs2015 comes with mussel library which is more like to use POSIX calls. I went through the installation guide provided and through the official link, came to know that I need to run configuration file followed by make.
But the configuration file has not been provided with vs2015.
I request you to let me know the procedure if someone has done this before.
musl doesn't support Windows; from the FAQ page:
What are musl’s dependencies?
Linux 2.6 or later. Earlier versions will suffice for running most simple single-threaded programs, but due to bugs and conformance issues at the kernel level, musl is not offically supported on earlier kernels.
(now, Windows 10 does support running Linux binaries through WSL, but in that case you would be building musl through gcc inside the Linux "container" and it would be another kind of game entirely)
As it comes as VS2015 along with third party license I thought there should be a way to get it done. The folder location is Microsoft Visual Studio 14.0\VC\vcpackages\IntelliSense\iOS\OSS\musl-1.1.10
As said in the comment, from the folder name it seems that it's there just to aid IntelliSense when editing code for iOS targets.
I am working on a project that depends on Lauterbach JTAG debugger hardware and software, and the support on the target JTAG cable ended in July 2011. We using a Linux 2.6.33 kernel on an omap2 processor. We are using gcc 4.9.2 to build the kernel image (not sure what version of bintools).
For those unfamiliar with how Lauterbach licenses its software, the target cable (connects between the debug pod and the target) carries the support contract dates. Any version of the Lauterbach Trace-32 software before and up to the end of the support period may be used, however anything after the end of support for the cable may not except for a 30 minute per session demo period. We are working through our purchasing process to renew the support contract for the cables, but until that is done (may take months), we're stuck with what we have.
It appears that the debug information produced by the toolchain we are using is too new for the last version of the Trace-32 debugger software released before July, 2017. Attempts to load the symbols for the kernel image (vmlinux) using the command:
data.load.elf \\path\to\vmlinux /nocode
fail with a message similar to:
error: entry near offset 5432100. in file \\path\to\vmlinux (use DUMP)
The easiest solution, of course, is to update to the first version of Trace-32 software that supports whatever ELF/DWARF combination that our toolchain produces. We know the most recent release works, but our cable does not support that version and won't until our procurement folks work out whether this is test equipment or software (they come out of different budgets).
For the next few months, we need a work-around. I'm looking for one of the following:
Some way to tell the toolchain to produce debug information compatible with the debugger software
Some way to convert the vmlinux ELF/DWARF file produced by our toolchain to an earlier ELF/DWARF format revision that is compatible with the Trace-32 build we are forced to use (R.2010.11.000028724).
Any other solution to the problem that we've not thought of
I thank everyone in advance for any help.
Edit: I'm not 100% sure whether the toolchain is producing DWARF3 or DWARF4, so it may be that I need to make a ELF/DWARF2 "vmlinux"
To your three ideas:
I suggest to try GCC's options: -g -gdwarf-2 -gstrict-dwarf Or maybe you can try a gcc version 4.4 (or older), which seem to fit to the year 2011.
I think you have no chance at all to transfer the DWARF info of an ELF to something else. (Or at least not in some easy way.)
Go to the Lauterbach website. At support > registration you can request a temporary maintenance key for one month. This should give your sales guys the time to buy a new key.
How can i find out this information?
Ie,
I can install boost 1.35 with a command like
sudo port install boost
only to get boost 1.36 via port i would do something like this?
sudo port install boost-1.36
Hope that clears up my question
I believe this is the relevant ticket.
There's a new Portfile in the ticket, and that works fine for me.
I believe the ticket is still open because of issues relating to Python and MPI.
Boost 1.36 is already available for OS X: http://www.boost.org/users/download/version_1_36_0
Not sure exactly what you're asking, but OS X is a supported platform for that release and the sources download is the same for all platforms.
The Boost website distributes source code, which may be compiled on any supported platform (including Macs). It is, therefore, available now.
That depends on what package manager you're using. OS X doesn't come with one, so any packaging will be by third parties. If you install software using MacPorts, please file a bug requesting an updated version of the Boost package.
Now that I see you're looking for a MacPorts update, in addition to filing a bug as John suggested, you may find it useful to contact the boost macport package maintainer and ask when it might be available. Contact info is available here: http://www.macports.org/ports.php?by=library&substr=boost