I've written a program which uses a lot of the new features in C++11. I wrote it on MacOS X, it compiles and runs fine with Apple Clang, Boost 1.5* and libc++ (assumption, as opposed to libstdc++). The program is for personal use and it won't need to be deployed on more than a few servers.
I shipped the production server to its overseas location with CentOS 6.5 installed. So I built a dev server with CentOS 6.5 installed. Pushed my code up to the dev server, used the package manager to get everything I thought I needed and then tried to compile - only to be bitterly disappointed.
Problem: I think the Clang version from EPEL is fine. However it wasn't playing nice with libstdc++ provided by the base repo - CentOS 6.5 is only up to GCC ~4.4. For example, I couldn't get GTest to compile. So I searched around and found a repo called the devtoolset-2 which had GCC ~4.8. It was made clear that this repo should only be used for testing purposes. Using the libstdc++ from this worked much better. However, now I was having a few boost problems - as the base CentOS 6.5 repo is only up to ~1.44. I've been trying to get 1.55 installed but failing... tried from repos and building myself but I'm guessing other dependencies are still out of date - e.g. Binutils. Either way it had all been a big mess.
I think moving the dev server to CentOS 7 would make things much easier. However, it is not going to be easy to move my production server over.
Basically I'm looking for advice. Can I build on CentOS 7 and copy the required libraries over to the production server? And what are the potential pitfalls of this? Should I statically link everything - including libstdc++? Or are there any other suggestions - apart from moving the production server to CentOS 7 (which I'll try do if I absolutely need to).
If you think this is not a 'stackoverflow' question please let me know.
Thanks.
John.
Related
I have gcc 6.3.0 and to run tensorflow 2.11.0 along with cuda 11.2, I require gcc version 9.3.1, but I just cannot find a simple and straightforward way to do that. Some people say install mysys, other sites point to sourceforge download link, while download links on mingw site point to github repos, I just don't understand how to upgrade this thing. It would be really helpful if someone could explain it like you are explaining it to complete newbie, step by step.
Last time, I downloaded mysys2 because someone told that it will automatically upgrade gcc to latest version, mysys2 came with a python 3.10, and I was working with python 3.9, and it created a lot of issues, later I had to reset my pc. That's way I just want to know the direct way to upgrade this thing instead of upgrading other software. I also tried by downloading mingw, but the installer available on sourceforge gives gcc 6.3.0 and not the latest gcc. And what is this cygwin which gives unix like environment, why do i require unix like environment. Even if cygwin can do it easily, I am hesitant to download cygwin, cause i don't want another repeat of tragedy that happened due to mysys2, afterall, installing a complete set of programs that i don't know anything about and will probably never use will only create additional errors.
I recently installed the windows branch of Caffe onto my windows machine. It works fine but then we I tried running some other projects I found online they didn't work at all and gave me all kinds of errors.
I think the reason it doesn't work is because they were using a different branch of caffe, this one for instance.
Is there a fix to this problem? Can I run ssd caffe on windows somehow?
The Caffe-SSD is not a branch, but a fork of the vanilla Caffe. Compiling and using Caffe on Windows requires certain effort (e.g. pre-building some external libs, adjusting CMake config etc.), which was not done for the Caffe-SSD fork.
You need to merge the contributions from the Windows branch into the Caffe-SSD. There are some existing solutions for that (https://github.com/runhang/caffe-ssd-windows, https://github.com/gustavkkk/caffe-ssd-win, google for more), but I did not use those.
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)
Apologies if this is more Server Fault than SO, but it is related to coding so here goes...
I have someone else's code that I am trying to compile on RHEL 7 but will run (for the moment at least) on RHEL 6. I've written my own RPM spec file to build and output an RPM file. The RPM builds fine on both RHEL 6 and RHEL 7 but when I build it on RHEL 7, does not produce an RPM which can be installed on RHEL 6 due to versions of GLIBC.
Is there a simple switch I can add to the build somewhere which will allow the resulting binary to be satisfied with an earlier version of GLIBC and be able to be installed on RHEL 6?
To be clear, I don't actually need a RHEL 7 binary at present, I'd just like to be able to compile for RHEL 6 on a RHEL 7 dev box.
You can use mock (sadly only in EPEL) to create a Red Hat Enterprise Linux 6 chroot on your Red Hat Enterprise Linux 7 system. If you use only libraries with Tier 1 ABI compatibility, your application will continue to run on Red Hat Enterprise Linux 7 without recompilation. Building on the oldest supported release (from the application point of view) is really the only way to do this. If you need a more recent C++ compiler and that's the reason why you are building on Red Hat Enterprise Linux 7, consider using Developer Toolset (DTS) instead.
Tier 1 libraries are described in the Application Compatibility Guide. There is supposed to be a PDF attachment with the previous list of packages, but I cannot access this right now.
I would like to try scidb as a replacement for hdf5. I would like to test it on my Debian laptop (no clusters) to give it a try.
Is this possible? Might be that Debian (as opposed to Ubuntu) is not supported?
I had no luck with the installation instructions. The deployment script tells that my OS is not supported. The scidb userguide says about some pre-built packages (for Ubuntu, at least). But there is no hint on how to obtain them.
SciDB is limited to RedHat / CentOS, and to Ubuntu as of the 14.9 release. Folk who want to run it on other distros generally compile from code.
Information about how to obtain the sources (as well as current documentation and community discussion) can be found on the forums here ... http://www.scidb.org/forum/. You'll need to register as a forum user.
Specifically, have a look at http://www.scidb.org/forum/viewtopic.php?f=16&t=364. There's a list of releases and links to code bundles there.
I installed SciDB several times using several ways (building from sources and installing from packages, installing the cluster version and the dev version).
Installation from packages
First, if you choose to install from packages (the easiest and fastest way), SciDB is very very sensitive about your Linux version. For example, for the last version of SciDB (14.8), if you choose to install on a Ubuntu, it has to be a Ubuntu 12.04 (and not a 14.04, a common mistake) 64 bits (meaning you have to install the AMD64 version even if you have an Intel processor). It won't work if you have a different version.
If you have an Ubuntu 12.04 AMD64, Paradigm4 provides a deployment script and a documentation with very simple steps:
https://github.com/Paradigm4/deployment
Installation from sources
It's not so difficult but it can be painful and time consuming. I did it because we had to compile a custom plugin for SciDB. You have two types of installation: dev install (in SciDB user directory) and cluster install (in /opt/ directory).
You have to be registered on their forum to have the link to the source code. They provide a specific documentation to build from source.
Good luck.
Several months ago I have dealt with porting SciDB 14.12 to an unsupported Linux - Fedora 19. If your OS is not supported, it will neither be supported if you try to install from the sources. You have to start from the sources, but then you have to adapt the deployment and installation scripts. The sources can be downloaded from SciDB forum.
Namely, add a new platform to deployment/common/os_detect.sh. Then, there are multiple platform specific deployment scripts, such as deployment/common/prepare_toolchain.sh, deployment/common/prepare_coordinator.sh and deployment/common/prepare_chroot.sh. You need to make sure those prepare the environment as they would on the supported OS'. I used Red Hat 6 and CentOS 6 as a reference, as those are both more similar to Fedora. Since your OS is Debian, you can first try falling back to Ubuntu deployment (in os_detect.sh).
Another problem you may encounter are the 3rd party tools, specially Boost. In my case, I had to build it manually from sources.
Sometimes when porting and debugging it is not convenient to run the scripts with deploy.sh, but it's better to run the deployment scripts directly on the target machine (e.g. coordinator).
Probably the best way to install and to start with SciDB is to download a standard image. With this image you only have to import the virtual machine with a software to virtualize. Moreover there are some characteristics of this virtual machine that are great to develop your first applications.
The main advantage, is that you have an API to SciDB queries and another to R. Then you can explore all options and to test SciDB.
This is the version that I downloaded few months ago: http://www.paradigm4.com/forum/viewtopic.php?f=14&t=1329&sid=606f614e401900cfa750375ba56de656
Nevertheless, there is a problem, the community is too poor. There are little people developing with SciDB.