My linux environment is based off of a high compute cluster that does not allow users to install to /usr/bin/ or use sudo. I'm trying to use ./configure (made from protocol buffers) to install to my home. When configure searches for the CXX files it is not finding the compilers that are located in the bin because they are named things like 'g++34' instead of 'g++'. I want to point the configure file at this specific compiler, but can't seem to get the command right to do so. Again the directory where the compiler is gets searched, it is just named funny (using an alias hasn't worked either).
How do you use a arguments in a configure file to point at a specific compiler?
Just use:
./configure CC=gcc34 CXX=g++34
etc. If you have a really old version of configure you might have to do it via the environment instead:
CC=gcc34 CXX=g++34 ./configure
Related
I want to install Libav locally in a folder and for that I have to install yasm (I can disable the dependency but I don't want to just for the sake of the argument). The installation of the package is done in the terminal via "./configure" and "make" (when I run "./configure" I receive the message, that yasm is missing). How can I tell to "./configure" to take it's yasm dependencies from the path "./libs" (there is a folder with libraries in the parent folder). Should I modify the makefile (and if yes should I change only the LDflags? to what?) or add the " --extra-ldflags="-L./libs" " to the ./configure command? What would be the use of cflags here?
To have autotools' configure use dependencies from a specific directory, the following may or may not work, as the configure script can be written differently:
--extra-ldflags (there should be --extra-cflags too) is fine, if it's there;
for library dependencies, you can add CFLAGS="-I<path>" CXXFLAGS="<same>" LDFLAGS="-L<path>" to ./configure's environment or to its command line arguments;
cleaner approach: if you have pkg-config configuration generated and installed for your dependencies, you can specify a PKG_CONFIG_PATH instead. In special cases of cross-compilation, one can use PKG_CONFIG_SYSROOT_DIR.
for local host executables, append/prepend to PATH.
Related question: https://unix.stackexchange.com/questions/19663/how-to-change-the-compiler-settings-with-automake
I've been trying to install LuaJIT on Windows 10 for some time following the official guide, and I actually get to install it. For example, if I execute luajit I get into the prompt. Also, luajit -v returns the version of luajit (2.0.4). And I can also execute code with luajit -e <lua code>. However, whenever I try to save bytecode with luajit -b, I get the following message:
luajit: unknown luaJIT command or jit.* modules not installed
I tried to make all sort of installations: using Cygwin, luajit-rocks, MinGW, ... However, no matter what I try, I always get the same result, and I have no clue of what to do.
Could you point me to some potential problems I might be overlooking?
I have on my system Lua 5.1 and Luarocks.
Some extra LuaJIT features are implemented as separate Lua modules (e.g. jit.bcsave for bytecode saving), and LuaJIT depends on package.path to find those modules. The suggested install location for those modules is in the default package.path, but if you override it via the LUA_PATH environment variable, you have to make sure to include that location there. One easy way to do that is to put two consecutive semicolons into LUA_PATH: Double semicolons are replaced by the compile-time default value of package.path.
You need place modules to "jit" folder near with juajit.exe. That folder include some system modules (bcsave too). package.path can dont work, becouse it hardlinked, how i understand. That folders distributed with source code.
Download lua from official sice: https://luajit.org/download.html
You can see "jit" folder inside archive:
LuaJIT-2.0.5.zip\LuaJIT-2.0.5\src\jit\
i'm tackling the problem of compiling vmime library using this guide with MinGW. As this guide states, first i need to compile libiconv library with these commands(yep i'm new to MinGW):
$ tar -xvvzf libiconv-1.13.1.tar.gz
$ cd ./libiconv-1.13.1
$ ./configure --prefix=/mingw #configures makefile, use /mingw as a prefix
$ make
$ make install
after all this commands the libiconv.dll.a appears in libiconv-1.13.1\lib.libs
directory.Also after compiling process appears the /bin directory and there is only 1 library - libcharset-1.dll.
My question is - how do i know if the library properly compiled, without errors?Should i check the output from the MSYS console? there are tons of checks, it seems pretty boring task. Thanks in advance, glad to hear any advice!
You're building a GNU Autotools package.
./configure generates the makefile(s) needed by make to build the library
on your particular system. If it thinks the library can't be built on your particular
system, it will tell you why. It might just miss some reason why you can't build
the library, because the library developer(s) have to script the tests that it runs, and might
just overlook some necessary ones. But if it misses something then make will fail.
make executes all the commands necessary to build the library on your system. If any of them fail,
then make will fail, and will tell you so unmistakably.
Likewise make install does everything necessary to install the library
under the default or specified prefix path.
Classically, unix tools (like the autootols) will inform you when something goes wrong
and not inform you that nothing went wrong.
I'm trying to install ncurses to a non system-wide prefix (for cross compilation).
Everything worked fine and I was able to install ncurses to the specified prefix, with the header files residing in <prefix>/include/ncurses.
A program I'm trying to compile (specifically GHC) doesn't find the headers, because it tries to #include <ncurses.h>, which doesn't work. (include <ncurses/ncurses.h> does work though, but GHC doesn't try this.)
So I thought installing the headers to <prefix>/include directly would do the trick, but I wasn't able to this. Passing --includedir=<prefix>/include to the configure script of ncurses didn't give the desired result, because the installed ncurses.h then tries to #include <include/ncurses_dll.h>, which doesn't work.
<prefix>/include is of course in the search path of the used CPP.
As a rule, --includedir for autoconf-based configure scripts is used to tell the makefiles where to install header files, not where to include them from during compilation.
Instead, the options that you might want to set would be in the CPPFLAGS variable. For instance, since GHC expects the ncurses header files only in the standard location, you might work around the problem by specifying both of the directories as -I options in CPPFLAGS.
Here are a few discussions to help:
4.8.1 Preset Output Variables (autoconf manual)
how to set include paths with autotools
With autoconf/automake, how do I specify include file paths?
What is the difference between DEFS and CPPFLAGS in autoconf and automake
By the way, that prefix/lib looks odd...
Regarding the comment about --disable-overwrite, Linux and some other platforms default to enabling this feature. OSX for one does not. At the end of configuring, the configure script runs a makefile rule to show the resulting configuration. If overwrite is disabled, you would see a message like this:
** Include-directory is not in a standard location
I am trying to compile c-sources with the configure, make, make install trilogy.
Since I want to compile the sources so that they use another library (XYZ) that is not used by default, I can specify that with a
./configure --with-XYZ=yes
However, for the moment, XYZ is not installed in a default location, so I guess I can specify the path to the location of XYZ with that same configure script. If my guess is right, I'd appreciate if someone could point me towards the right direction of how to do that.
Specify the library path on the command line like this:
./configure --with-XYZ=yes LDFLAGS=-L/path/to/xyz
The most general way is to specify the LDFLAGS (for -L) and CPPFLAGS (for -I) variables, like ptomato described.
In many cases, there are other ways that are specific to the option and the package that provides it. Sometimes it might be --with-XYZ=PATH, sometimes it could be --with-XYZ-path=PATH, sometimes pkg-config is involved. You need to read the particular installation documentation, or more often than not do some detective work.