61

Try: DIR="$HOME/.bin-libevent" ./configure CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib" (I'm sure there must be a better way to configure library paths with autoconf. Usually there is a --with-libevent=dir option. But here, it seems there is no such option.)


51

This comes from automake, specifically from its AM_SANITY_CHECK macro, which is called from AM_INIT_AUTOMAKE, which is normally called early in configure.ac. The gist of this macro is: Check that the path to the source directory doesn't contain certain “unsafe” characters which can be hard to properly include in shell scripts makefiles. Check that ls ...


39

The correct way is: ./configure CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" but this may not work with all configure scripts. It's probably better to set environment variables such as CPATH and LIBRARY_PATH (see gcc man page). An example: export CPATH=/usr/local/include export LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH=/usr/local/lib ...


34

Executing (exit 1); is the simplest way of triggering an ERR trap. It will also trigger immediate exit if set -e is in effect. (Triggering the error condition requires a command to fail; exit with a failure value in a subshell causes the subshell to fail.) exit 1; will do neither of those things. So {(exit 1); exit 1;} can be used to first produce the ERR ...


31

If the file is called configure.ac, do $> autoconf Depends: M4, Automake If you're not sure what to do, try $> cat readme They must mean that you use "autoconf" to generate an executable "configure" file. So the order is: $> autoconf $> ./configure $> make $> make install


30

I believe the automake process involving a Makefile.in is something like this: Makefile.am | \'/ +--------------+ | automake | +--------------+ | \'/ Makefile.in | \'/ +--------------+ +--------------+ | ./configure |<-- | autoconf |<-- configure.in +--------------+ +--------------+ | ...


18

it's just a convention that signifies the given file is for input; in my experience, these files tend to be a sort of generic template from which a specific output file or script results.


17

The configure script is a script that will configure the software that it was distributed with for compilation (if applicable) and installation. These scripts are often (as in this case) created by GNU autoconf (a tool used by developers specifically for creating portable configure scripts), which means that it will have at least a minimum of a certain set ...


15

./configure usually creates a config.log file. It should contain the commands executed to check for the library.


11

To install to a custom directory, use this: ./configure --prefix=/desired/path make sudo make install By default, programs installed without the added prefix will be located in /usr/local/bin. To verify this, you can type which program_name after installation. If you install your program in a custom directory, it will be installed in /desired/path/bin. ...


10

In this case VAR=value ./configure the behavior depends on your current shell, while in this ./configure VAR=value the behavior depends on the configure-script. Some of the developers prefer the latter because they would like to choose whether to set variables within the script, rather than have someone magically set the script's variables from outside. ...


9

I was having a similar problem and discovered that after running sudo yum install libevent-devel I was able to successfully make and install tmux. EDIT: If you are installing this on a Red Hat machine, you will also need to visit the channels selection for your server on the Red Hat Network and add the RHEL Server Optional channel. This will give you ...


9

The failsafe for generating a configure script is autoreconf -i, which not only takes care of calling autoconf itself, but also a host of other tools that may be needed.


9

The simple approach in your case is to install the open-vm-tools package. To address your question, there is no fool-proof way of listing all missing packages at once, mostly because this wasn’t designed in and configure scripts allow their authors to do anything — so there’s no way to know in advance how to continue and whether continuing is safe. An ...


8

You'll have to grab the package's source RPM. For example, with apache httpd: yumdownloader --source httpd You can extract just the spec file from the source rpm with: rpm2cpio httpd-version.src.rpm | cpio -i httpd.spec Then, search for the %build section in the RPM spec file. Sadly, CentOS doesn't appear to keep their spec files in any kind of public ...


8

There is no purpose for this as far as I can see, there is nothing that can be achieved directly by starting a subshell and then immediately exiting. Things like this are most likely a side effect of automatically generating code - in some cases there may be other commands executed in the subshell where having the exit 1 makes sense. Ultimately there is a ...


8

The first syntax is correct. ./configure CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" However, it is strongly recommended to either use binary packages(7) or, if for whatever reason you absolutely need to build from source, make use of the ports(7) infrastructure, as explained by the FAQ section 15. Set up the ports tree as detailed in the FAQ....


7

There should be a package called liblo-dev on Debian that should provide this header. Simply install it using apt-get or aptitude: aptitude install liblo-dev


7

You are correct regarding the Makefile the only things that happen are defined in it or companion scripts that get run. "Best practices" when upgrading software from source is typically to use the uninstall option if you did not run a make clean or delete your original source installation directory. You have to be careful though, should the program have ...


6

I had the same issue on RHEL 5.4 and actually found libevent is installed but there is no libevent.so symlink, only the real version of the library: /usr/lib64/libevent-1.1a.so.1 /usr/lib64/libevent-1.1a.so.1.0.2 So, ln -s /usr/lib64/libevent-1.1a.so.1 /usr/lib64/libevent.so works pretty well for me without the need to install or alter anything. No idea ...


6

configure scripts produce config.log (in the same folder) files which contain all the details on the tests it ran. They're not particularly easy to read, but open it up and search for "checking ncurses.h usability". Look at what went wrong with the small test program it tried to compile. My guess is, it doesn't care about $C_INCLUDE_PATH and you'll need to ...


6

They are input files for the m4 macro preprocessor. Among other things, these files contain macros marked by @, that get expanded by m4.


6

According to this thread, you should just install libXt-devel package and you should be fine. But perhaps you also should install xorg-x11-server-devel and libX11-devel? That would be: yum install xorg-x11-server-devel libX11-devel libXt-devel


6

./configure scripts look for minix/config.h to determine whether they're building on Minix, or not. The test is defined in specific.m4. Autoconf sets a couple of variables up when it detects Minix, that's all it does — of course, specific builds may then react differently, but that depends on the project being built, not on Autoconf. As you've noticed, the ...


6

That’s a sanity check, to ensure that the configuration script is correctly able to determine whether a header file is present or not: it asks the compiler to use a non-existant header, and checks that the compiler (correctly) fails. Note that your build goes on after that “error”... To figure out the cause of a build failure, you should generally work up ...


5

Yes, and no. Removing source file won't affect installed binaries and other resources, But you should keep them, in case you need to rebuild them. i.e when system libraries updated, it's likely for you to rebuild / re-link the binary


5

When configuring Subversion, try ./configure --with-apr=/usr/local/apr/ That might not be exactly the right path. Try finding apr-config and giving the path to that. I'm guessing it might be: ./configure --with-apr=/usr/local/apr/bin/apr-config Try ./configure --help to see what your options are. There are a lot of them.


5

To set the default device, you should not redefine the default device but simply put the following into /etc/asound.conf: defaults.pcm.card 2 # or better "PCH" defaults.pcm.device 0 This will work only for programs that actually use a default device without explicitly specifying a device. If some program like PulseAudio or VLC has been configured for ...


5

The test is done by compiling a small dummy C program and by checking how the compiler names the output file. The following example is a simplified version of what configure is doing #!/bin/sh cat << EOT > dummy.c int main(int argc, char ** argv) { return 0; } EOT gcc -o dummy dummy.c if [ -f dummy.exe ] ; then # exe fi I would suggest ...


5

This option was added to address xterm flickering (on some setups) when resizing/scrolling back/long outputs. The initial patch was posted by a user on Archlinux forums. It was later integrated into xterm source code.


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