Can anyone explain what 'configure' is and does, where the config.log file can be found in general?
This is in relation to a specific problem ( gcc not working - Xcode 3.2.6 - Snow Leopard ) but I thought this question might be of more general interest:
When trying to install rubies with RVM, and I think possibly anything involving Xcode's gcc compiler, or possibly even more general than that, if there are errors then the logs usually refer to a config.log file. E.g. in my /yaml/configure.log I get:
configure: error: in `/Users/duncanstuart/.rvm/src/yaml-0.1.4':
configure: error: C compiler cannot create executables
See `config.log' for more details
Googling around suggests that this file is specific to the package being installed, but various posts give a number of different locations, none of which exist on my machine - e.g. Error installing PostgreSQL on Mac OS X 10.5 using MacPorts says it's somewhere under /opt/local/var/
Can't install Ruby under Lion with RVM – GCC issues contains an example config.log which says:
This file contains any messages produced by compilers while running
configure, to aid debugging if configure makes a mistake.
configure is part of a common source package layout - it's usually responsible for inspecting the target system and seeing what compilers, syscalls, libraries etc. are available on it. Using this information features are then enabled/disabled at build time.
Often (thought not always) it is automatically generated by autoconf from configure.ac (or configure.in).
config.log is used to store the results of tests - this can be useful to developers or to try and figure out why some optional feature was not built. It's stored in the current directory, at the time configure was called, thus for "in tree" builds it would be found at /Users/duncanstuart/.rvm/src/yaml-0.1.4 (or possibly a directory or two up if there was a sub directory being configured).
Related
I've been trying to install hmatrix on my (64-bit) Windows 10 computer; after searching through and trying many possible solutions (including the instructions under "Windows" and "Alternative Windows Build" given here), I decided to pursue the course of action given on this Reddit thread.
However, when I type in the command
cabal install hmatrix -fopenblas --extra-lib-dir=${c:\msys64\mingw64\bin} --extra-include-dir=${c:\msys64\mingw64\include}
into the MSYS2 shell, the following log is given:
Resolving dependencies...
Configuring hmatrix-0.17.0.2...
Failed to install hmatrix-0.17.0.2
Build log ( C:\Users\Christian\AppData\Roaming\cabal\logs\hmatrix-0.17.0.2.log ):
Configuring hmatrix-0.17.0.2...
cabal.exe: Missing dependency on a foreign library:
* Missing C library: libopenblas
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
cabal: Leaving directory 'C:\msys64\tmp\cabal-tmp-4244\hmatrix-0.17.0.2'
cabal.exe: Error: some packages failed to install:
hmatrix-0.17.0.2 failed during the configure step. The exception was:
ExitFailure 1
However, when I check the directory c:\msys64\mingw64\bin, I see that libopenblas.dll is right there; I don't know why cabal can't seem to find it.
Any insight into why this is not working or what to do?
UPDATE:
The files libopenblas.dll.a and libopenblas.a are in the directory c:\msys64\mingw64\lib. Is it possible I need to somehow include this directory as well? (If I do, how would I do that?)
I also downloaded the files in Alex Vorobiev's comment below and put them in c:\msys64\mingw64\bin if they are .dlls or c:\msys64\mingw64\lib if they are .libs. The header files were already contained in c:\msys64\include\openblas.
I tried several variations on the command in the original post after making these changes, including switching \bin with \lib and switching \include with \include\openblas, but all of them still give the same error.
I'm a bit suspicious about the
if os(windows)
if flag(openblas)
extra-libraries: libopenblas
in the cabal file, could you unpack it and remove the "lib" part? If that doesn't work please post a log with -v3 output. I've seen quite a few people with troubles installing this package. So could you also open a ticket on the GHC bug tracker if this doesn't work (and CC me "Phyx-")?
Secondly, you never said which version of GHC you're using. 8.0.1 should have far less trouble (and won't need the hack to get it working in GHCi) since the runtime linker has been overhauled and should be much better on Windows. 8.0.2 will likely include the new import libraries support as well.
I am trying to compile "xz-5.2.1" in MinGW/MSYS environment. I see the following errors:
#error UINT32_C is not defined and unsigned int is not 32-bit.
error: #error size_t is not 32-bit or 64-bit
I am not familiar with MinGW, could anyone shed some light on this? It looks like some macro definition are missing. Some header file missing?
ADD 1
The commands I used to compile the xz-5.2.1 are:
./configure
./make
The error screenshot:
Some background, I am following this link to compile the Tesseract-OCR library. And this is just one of the steps.
ADD 2
Based on the error message, I checked the sysdefs.h file. It contains the following content:
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
The above make output contains the -DHAVE_CONFIG_H, so I think the system header file <config.h> should be included.
But strange enough, I searched the C:\MinGW\include, there's no such file. So I GUESS this may have caused the undefined UINT_MAX warning at line 57. And then the UINT32_C is not defined error at line 58.
But I don't know why the system header file config.h is missing and where to get it.
ADD 3
I dig a bit about the GNU autotools. And luckily enough I find that the following commands can carry on my build process: (Though I am still not very sure why it works. All I know is that it may be related to portability.)
autoheader (this generates the config.h.in file)
./Configure (this generates the config.h file from the config.h.in file)
And now, my build process is blocked by another issue as below:
It seems this is a known issue. And another thread has addressed it.
(I will continue update with my progress.)
If you care for an easier way to handle this kind of dependency management or a general update on toolchain functionality, I strongly suggest switching to MSYS2 with MinGW-w64.
Both projects aim (and succeed) in bringing a better version of the original. MSYS2 comes with a large number of 3rd party libraries that you can easily install. MinGW-w64 allows for GCC with full C++11/14/... support and extended Windows API availability, along with some useful extensions and more up to date headers. You'll notice that most problems originating from system headers will have already been solved, either by the MinGW-Packages scripts below, or upstream (of either MinGW-w64 or the projects themselves).
For you specifically, I suggest the following steps:
Install and update MSYS2.
Open an MSYS2 command prompt (or the 32-bit or 64-bit command prompts if you plan on building 32-bit or 64-bit things) from the start menu entries. Install {32-bit,64-bit} MinGW-w64 GCC:
pacman -S mingw-w64-{i686,x86_64}-gcc
Install tesseract-OCR:
pacman -S mingw-w64-{i686,x86_64}-tesseract-ocr
and optionally the data files:
pacman -S mingw-w64-tesseract-ocr-osd mingw-w64-{i686,x86_64}-tesseract-ocr-eng
And you're done. Of course, you can still compile the various dependencies yourself, but why bother? If you really want to, you can start from the build scripts for the packages you can install in MSYS2, which are located here:
https://github.com/Alexpux/MINGW-packages
Just open the PKGBUILD files and you can see the build steps required. Note that all these scripts assume the dependencies have been installed within MSYS2.
Also note that the installed packages and compilers are all independent of MSYS2 as you'd expect: you can use it only as a tool to keep your development tree up to date, and build from any other Windows environment.
I am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.
I am trying to compile a driver that we have from source and I am working through the issues with a new target environment. One of the slightly disturbing things I see is the following warning:
WARNING: Symbol version dump /usr/src/linux-2.6.38/Module.symvers
is missing; modules will have no dependencies and modversions.
I spent a fair amount of time looking on the web and this is shown in output frequently when other questions are asked, but I didn't see any commentary about whether or not this is an issue.
In any case, how would I tell linux/ubuntu to generate Module.symvers?
Module.symvers is generated when the kernel itself is compiled and ought to be provided to the user as part of the kernel build environment package, however that may look on Ubuntu (possibly broken there?) Fedora and openSUSE for example ship one or more “kernel-devel” (and/or similarly-named) packages that ship this build environment and make the file reachable through /lib/modules/<version>/build/Module.symvers. When using a self-compiled kernel, substitue /lib/modules/version/build for the appropriate path to the build directory (where all the .o files are).