Hot answers tagged make
Some people will argue that the presence of development tools on a production machine will make life easier for an attacker. This however is such a tiny roadbump to an attacker, that any other argument you can find for or against installing the development tools will weigh more. If an attacker was able to penetrate the system so far, that they could invoke ...
make itself is fine. make is merely a dependency tracking and automation framework. It is typically used in conjunction with compilers, though, and those preferrably should not be available on a production system, as they're completely un-necessary. The same holds true for all un-needed packages, whether those be shared libraries, interpreters, etc. Software ...
make is a shell that has a different syntax than bash. A compiler like gcc is a powerful awk configured with a set of substitutions that standard awk does not support. It is a non-POSIX-compliant sort or cat that injects rubbish in the output. It is an interactive text editor (think vi) which is configured to do some editing on startup, then exit before ...
Usually it is something like that. ./configure This (when executed in the directory your source code is), creates a Makefile with the rules that will be used to build the program. This is where you can change the behavior of the compilation (that is, compile the program with options that are not default). make This builds the program with the rules ...
One more thing - once you install xCode 4.3 from the OS X App Store, launch xCode, then go to Preferences -> Downloads and install "Command Line Tools". Restart Terminal and you will be able to use Make.
Have you upgraded the Mac OS since installing XCode? System updates, major ones anyway like 10.5 to 10.6, may remove those programs from /usr/bin. Download the latest Xcode and reinstall. It should put them back.
On the contrary, the potential issue isn't with having make on the production server, the potential issue is with building the applications on the production server instead of deploying tested pre-built images. There may be valid reasons for this methodology, but it's one I would argue against strenuously were I asked to adopt it.
I've just had the same error and fixed it with the below. cpan o conf make '/usr/bin/make' #or path to your make o conf commit
Just use make -j 3 and it should compile in paralell, and will ensure any dependencies are properly handeled, this is the "official" way to do it.
You can make a symbolic link yourself: which make (to be sure it's there) cd /usr/bin ln -s /Developer/usr/bin/make make
When you get the new source, check the README or INSTALL files. Often there will be a section about upgrading. If there is not, doing a make && make install should work.
When you compiled Apache you should have "--enable-so". I think you must have because the so module is trying to load. Also after compiling openssl ensure the system can find the shared library with "/sbin/ldconfig -v /usr/local/openssl/lib" and I also like to edit /etc/ld.so.conf.d/local.conf to add a line for /usr/local/openssl/lib
The file include/generated/autoconf.h is generated in the make prepare step. If you are trying to build a kernel module, you will also need the make scripts step: gunzip < /proc/config.gz > .config make oldconfig make prepare make scripts Usually the kernel is accompied with a headers package, have you tried installing that first? For CentOS, try ...
You’re asking if make should be installed on a production server, but my real question would be: Who has access to that production server & what safeguards do you have in place to deal with an incursion? If make was not installed but someone gain root access, guess what? They can manually install make and anything they want. The harsh reality about ...
I suggest recompiling the package in debian way: http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/ Just get the source from debian repository, add required module and build a new package. Version 1.4.1 is available in jessie. Your update is not successful probably because make install does not put nginx binary in /usr/sbin/nginx.
To stop a bit the looong chat going on, here's the C/C++ libraries you need for a compiled version of nginx with pagespeed on CentOS: linux-vdso.so.1 libpthread.so.0 libcrypt.so.1 libstdc++.so.6 librt.so.1 libm.so.6 libpcre.so.0 libssl.so.10 libcrypto.so.10 libdl.so.2 libz.so.1 libgcc_s.so.1 libc.so.6 /lib64/ld-linux-x86-64.so.2 libfreebl3.so ...
99% of time, just download the source of the new version (or a patch), build and install.
This is where GNU Stow can be useful. I've been using this tool for years to keep my OS clean. This is a package manager for programs installed from source. Here's how it works. First, I have one single directory where I keep all such programs, /usr/local/stow. Inside it, there are directories for each program. When I compile programs from source, I use ...
What I get the source for an application the first thing I do is to read the pretty standard README/INSTALL file. They usually tell me exactly what I need to do. They tell me what dependencies I will to install before I compile to get all the functionality I want. They tell me what I need to do to secure the install. less INSTALL less README Take 3-5 ...
Are you running make -j and creating parallel jobs? Sun has a nice guide about that. The hypervisor idea is a bit silly. You want speed and I/O performance, something that a single vmware server is going to take away from you. You probably want to setup as many cores and disks as possible. These would be the two real limiting factors of your build system. ...
Do you have any specific problem with yum? Normally you would do yum install make Or, maybe, sudo yum install make Wow :-), Ok, i write the standard Make reference here, you take your pick on the source. wget http://ftp.gnu.org/pub/gnu/make/make-3.81.tar.bz2 tar xfj make-3.81.tar.bz2 ./configure make sudo make install And, while you are there, might ...
Just download rpm: wget http://mirrors.cat.pdx.edu/centos/5.3/os/x86_64/CentOS/make-3.81-3.el5.x86_64.rpm and install it via rpm: rpm -ivh make-3.81-3.el5.x86_64.rpm
There is no way to guarantee that the make uninstall process for the new version will do the right thing with the version you have installed. You'd also need to make sure that you had identical configure options with your new and old version. The risk that it will do the wrong thing is just too great, especially if you're running this as root. This is one ...
220.127.116.11 is part of cygwin, if you select it in the mail package section.
As it happens, Cygwin's mutt package was updated to 1.5.20 with support for Unicode and other character sets yesterday.
I recall that openssl doesn't make shared libraries by default. I do this: ./Configure --prefix=/usr/local/openssl linux-elf shared Then you still have to do ldconfig as above. And tell apache where to find ssl libs.
You can increase swap size and potentially get this done. Maybe. It might just go into a spiral of thrashing death. But the better way is to abandon trying to build large software packages in that much memory. That's a really painfully small amount of RAM for a modern OS. Linux can be memory-light (that's why you can pay for a system like this, after all), ...
It seems that you are missing the required header files. Did you do this (from provided link)? This extension requires the Neon library and the related header files. You need to install the neon library from source or install the devel package if installing from RPM. If you think the library is already installed, you can check by locating the header ...
It depends on whether you are using mod_php or php cgi. Mod_php is loaded into memory when apache starts, so you can install php without affecting it. The new mod_php module will be loaded when you restart apache. PHP CGI on the other hand gets loaded every time a script runs. If you are installing PHP to a new location, that's fine, because apache will ...
Only top voted, non community-wiki answers of a minimum length are eligible