Tag Info

Hot answers tagged

4

Why would you [ab]use an enterprise OS by compiling PHP from source? If you're using CentOS this should be the absolute last resort. If you just need PHP 5.3.5 then I suggest using the IUS Community Repo. I have detailed usage instructions in my answer here.


4

You can see the configure options using the mysqlbug command-line utility. In your shell type mysqlbug and you'll see a template e-mail for bug submission. At the bottom end of that e-mail you can see the configure line with all the options your copy of MySQL was compiled with. The --with-mysqld-ldflags is omitted by default and it means the server will be ...


3

It won't get you exactly what you asked for, but you can check if a binary is statically linked or not (and if it is dynamically linked, what libraries it is linked against) with ldd. When the binary is dynamically linked, the output looks similar to this: $ ldd test-dyn linux-vdso.so.1 => (0x00007fffce7fe000) libc.so.6 => ...


2

Just use the default kernel for your (server) distribution. It won't matter for dev purposes and for tuning a production system you need an expert anyway (who will look at the kernel compilation options last).


2

Works for me: [me@risby ntp-4.2.6p5]$ ./configure --without-openssl && make [me@risby ntp-4.2.6p5]$ ldd ntpd/ntpd linux-vdso.so.1 => (0x00007fffd516c000) libm.so.6 => /lib64/libm.so.6 (0x0000003838a00000) librt.so.1 => /lib64/librt.so.1 (0x0000003838600000) libc.so.6 => /lib64/libc.so.6 (0x0000003837a00000) ...


2

You will gain very little performance (if any), and you will need to take care of security fixes by your own. Always use software from official repository, unless you really, really have a good reason to do otherwise.


2

Red Hat Network distributes the source files for kernel versions, but not .patch files for custom personal backports. Most important vulnerabilities are backported by them, but again it's just in an appropriately versioned .src.rpm package. If you're hellbent on compiling your own kernel, then that's the route you need to take. Edit: If this is a ...


1

It is a Release Goal for the Debian Project to "update as many packages as possible to use security hardening build flags via dpkg-buildflags". When will this task be completed, is not stated in their wiki. So, to answer one of your questions, this is a decision made at the distro level, that maintainers need to implement. In the case of Debian, as you know, ...


1

As with many things, It Depends(tm). There's no correct answer to this for every situation. If you have performance concerns, do the following: Set up a machine with your application Install the default Debian package. Run whatever performance tests you need to run with a repeatable test load. Remove the debian package, install your compiled version and ...


1

I'm going to echo HoboDave's suggestion here. Compiling things from source on CentOS/RHEL is painful, conterproductive, and almost always completely unnecessary. So, question number one is: Why do you need to complile PHP from source? In case you weren't aware, RedHat maintains the latest security patches in its repository. So issues that are fixed in ...


1

Here is an example where you 'll see the steps for that process (looks like you're missing the apxs2 and the apache LoadModule directive in our question) : #!/bin/sh # #################################################### # PHP INSTALLATION SHELL for compiled version # By Hornetbzz - 17/09/2010 # localhost stands for the machine to be installed # ...


1

You installed the command line version only.. You didn't install the apache module. You need to add the following --with-apxs2 Make sure you have apache2-dev installed


1

I'd probably go with VMs; the hassle involved in trying to get cross-compiling toolchains going will drive you nuts, and the performance overhead should be fairly minor.


1

Error in source code, see ruby SVN. Install newer version ruby without error.


1

You could look into genkernel from gentoo linux, it seems to deal with issues you are concerned about.


1

First: You have an extraneous "e" in your --with-config-file-path flag. If the typo's in your real configure too then it could be a cause of your problem. Second: PHP needs to know where to load the extension from. You can tell it to search the directory you've noted by editing your php.ini as follows: extension_dir = ...


1

Is this for a specific embedded system? In general, changing compile options isn't going to make a big difference. Where performance matters, the modern kernel generally either automatically selects the best option, or else offers run-time tunables. You'd be better off working with those, or tuning your Java environment and your code.


1

You could just check your bash history if it is not long since you compiled the program. Some C programs embed the configuration in the binary PHP is one of those you can use strings to see that. strings /usr/bin/php | grep configure


1

In general, you can't, that information isn't stored anywhere. Some programs' build systems are designed to store a copy of the configure script invocation used to set up the build environment, but that behavior has to be written into the program. It doesn't get done automatically. If you're desperate I suppose you could always try compiling the program ...



Only top voted, non community-wiki answers of a minimum length are eligible