Why does Apache website lists only two OS for mod_jk binaries?
I am confused about which version to download to install on Linux2.6.9 OS. From their website all I understand is that I have to download source and compile to create binaries for my OS? Am I correct?
I looked up tutorials on the net and they all seem to reference some old binaries for linux versions. If Apache did provide pre-compiled mod_jk modules why did they discontinue them?
I would go for mod_proxy_ajp. It's supposed to be a newer replacement for mod_jk.
As fas as i know you should always download latest one from http://tomcat.apache.org/connectors-doc/ compile it in your local system.
Under Debian install it with apt-get:
apt-get install libapache2-mod-jk
Related
In Cygwin, I'm attempting to install openmpi 3.1.6-1. Unfortunately, I can only find newer versions of 4.1.0-1 and 4.0.5-1, not the one I'm seeking for. I went to the website https://www-lb.open-mpi.org/software/ompi/v3.1/ and discovered the openmpi 3.1.6-1 version.
Now, how do I go about installing it from this website? or is there a different option?
Openmpi 3.1.x is binary compatible with 4.x
https://sourceware.org/pipermail/cygwin-announce/2020-May/009518.html
https://sourceware.org/pipermail/cygwin-announce/2021-November/010320.html
Both have the same shared libraries
libopenmpi40
libopenmpifh40
libopenmpiusef08_40
libopenmpiusetkr40
Why do you think you absolutely need 3.1.6 ?
For easy deployment, I'd like to ship an installation of Postgres as part of the application. Is it possible to include an already compiled and runnable version of Postgres that can be launched as process? I was able to do such thing with a Windows and MacOS version, but haven't found anything about Linux on that matter yet. Perhaps someone has tried this before and can share some insights...
You haven't stated what linux OS you're using.
Assuming it's a Redhat variant why not package your application as an RPM package? You could then declare a dependency on the standard Postgres package which would be automatically installed yum. Same principle applies if you're using Debian based systems, just a different packaging format.
From the user's perspective the OS's native packaging format is always the easiest way to install your application. Just requires effort to package it properly.
You can find cross-platform binaries from these pages on PostgreSQL official website:
For easy GUI .run installers, use links provided at http://www.enterprisedb.com/products-services-training/pgdownload.
If your target machine has no X installed on it, or you want to automate installation process with shell scripts, then you can download RPM or Deb packages from http://community.openscg.com/se/postgresql/packages.jsp
I found these links on http://www.postgresql.org/download/linux/ubuntu/, under "Cross distribution packages" and "Graphical installer".
I quote from those pages:
Note: The cross distribution packages do not fully integrate with the platform-specific packaging systems.
You must have root priviliges to install these packages, however, none of your systems library files will be altered. The supporting libraries that these binaries require are included locally as part of the install. This is the "special sauce" that allows identical binaries to run on different linux distro's.
I have a project that runs on Debian and uses many packages provided from the Debian repositories.
Because of demand, I've looked into porting the project to CentOS, but found that many of the packages I require are completely missing - at least 10 dependencies would have to be compiled manually at install time on the users machine.
My question is, what is the best way to create an installer for the user's machine? Should I use automake tools (with the standard ./configure, make, make install), to compile the required libraries, or is this a non-standard approach. Note that my app doesn't actually need to be compiled since it is written in Python, so is it weird to do a "make", when you're not compiling your own app?
Should the configure script just warn the user that package X is missing, and let them handle the rest?
Should I roll my own dependency checker by runng pkg-config manually a few times for each library required, and exit if something is missing?
I'm quite new to this, so any tips to get me moving in the right direction are appreciated.
Edit: I am familiar with RPM and yum for red hat base distros, but CentOS is missing many multimedia packages that I require. An example of one of my package dependencies is "liquidsoap" which is a programmable audio engine: http://savonet.sourceforge.net/
This is available on Debian, but not Redhat/Centos
See this link on CentOS package management.
http://wiki.centos.org/PackageManagement/Yum
CentOS is redhat based and does not use .deb packages by default. However apt package management has been ported to tons of platforms, you may be able to use a port for centOS
If you use YUM whatever packages you need will be there for your application as redhat distros need all the same things that any other distro does.
EDIT: To get the details out of comments
Packages not available on the target platform either have to be built (possibly as a port) on the target platform and then shipped in the ported package (in this case YUM), or code needs to be modified and forked to use packages which already are available on the target platform. The choice depends on which is worse, or which is even possible given your constraints.
While porting Qt project from windows to linux(ubuntu) i faced with the following issue:
on windows Qt version 4.8.1 is installed
on linux 4.6.3 in which some functionalities availiable in higer version 4.8.1 don`t yet implemented (ex. QUdpSocket::joinMultiCastGroup).
I see only one solution to this problem: upgrade Qt version on linux to 4.8.1.
How can I do this?
On linux I got installed libqt4-dev, qmake.
Solved: I changed repository from squeeze (stable) to wheezy(testing), in wheezy latest Qt version is 4.8.1, which is perfectly suits my needs.
Using package manager I found package libqt4-dev and selected it for update.
That is all, the whole process took 5 minutes.
Disadvantages:
- As I run Debian on Virtual Box after changing repository I had to reinstall guest additions
- wheezy is less stable than squeeze (I haven`t faced yet with stablilty problem)
I guess you can use Upgrade option in the Qt Creator.
Or you can download latest version from Download Qt, the cross-platform application framework
Or you could try to update using something like apt-get install(upgrade) libqt4-dev if you using Debian based system.
This depends on the distro you are using. If there are binary packages for your distro you can update through your package manager. Otherwise you have to download the source of your prefered Qt version and build it yourself.
I'm not sure if this will help in your situation, but you can download the Qt Online Installer at the following link:
https://www.qt.io/download-qt-installer
Can I install an older version of gcc/g++ (4.1.3) on the latest Ubuntu (which comes with 4.4.3) and use it to compile a .so which should run on CentOS? The binary compiled with the Ubuntu version of gcc fails to load on CentOS because of missing imports (GLIB_2_11, ...). I need C++ (including exceptions), so I can't just statically link against glibc, which I already tried.
Can I install the older gcc without removing the newer one? How do I go about the libs required by the older gcc?
I'm currently developing code in CentOS, but it's such a pain to use. I really want to move to an Ubuntu desktop.
g++-4.1 is available for Ubuntu; just run apt-get install g++-4.1 then run g++-4.1 instead of g++. However, simply using an older compiler may not fix all of your library issues.
Like Joachim Sauer said, your best bet is to do your development on Ubuntu then do the final compilation on CentOS.
Even though you're using C++, static linking should still be an option. (However, you're much better off compiling on CentOS and using dynamic linking.)
Edit: A virtual machine is the most straightforward way to build on CentOS, but if you want to avoid the memory and CPU overhead of running a VM and don't care about differences between Ubuntu's and CentOS's kernel, then you can create a subdirectory containing a CentOS or Fedora filesystem and chroot do that to do your builds. This blog posting has details.