If I don't have pkg-config installed nor glib my configure breaks with a syntax error when running ./configure. Is there a way to break with AC_MSG_ERROR?
./configure: line 4001: syntax error near unexpected token `GLIB2,'
./configure: line 4001: ` PKG_CHECK_MODULES(GLIB2, glib-2.0, , as_fn_error $? "glib needed" "$LINENO" 5)'
--
AC_ARG_ENABLE(GTK, [], [gtk="$enabled"], gtk=no)
if test "$gtk" = "yes"; then
AC_CHECK_LIB([gtk-x11-2.0], [gtk_init], [], [AC_MSG_ERROR([gtk needed])])
else
AC_CHECK_PROG(HAVE_PKG_CONFIG, pkg-config, yes)
if test x"$HAVE_PKG_CONFIG" != x"yes" ; then
AC_MSG_ERROR([pkg-config])
fi
PKG_CHECK_MODULES(GLIB2, glib-2.0, [], AC_MSG_ERROR([glib needed]))
AC_SUBST(GLIB2_CFLAGS)
AC_SUBST(GLIB2_LIBS)
AC_CHECK_LIB([glib-2.0], [g_list_append], [], [AC_MSG_ERROR([glib needed])])
fi
AM_CONDITIONAL([GTK], [test "x$gtk" = "xyes"])
The configure script was generated incorrectly, in absence of pkg.m4. For all non-basic macros that don't start with AC_* it's a good idea to distribute them with the source code for this reason, so you can at least get a correct configure script.
That said, pkg-config is pretty ubiquitous nowadays, why are you generating a configure script from a system that doesn't have it? You could simply make dist from a "better" system, and build from the output tarball (that will contain a valid configure script).
Adding a check for pkg-config should do the trick:
# require pkg-config
AC_PATH_PROG([PKG_CONFIG], [pkg-config], [no])
AS_IF([test "x$PKG_CONFIG" = "xno"],[
AC_MSG_ERROR([
*** The pkg-config script could not be found. Make sure it is
*** in your path, or set the PKG_CONFIG environment variable
*** to the full path to pkg-config.])
])
Related
Getting this error during "make" in mpich
GEN lib/libmpi.la
libtool: error: only absolute run-paths are allowed
Compiler being used is clang (the code builds fine with gcc). Any idea what this error could be due to?
Here is the configure command:
./configure '--prefix=$PWD/BIN' '--with-device=ch3:nemesis:mxm' '--with-mxm=/home/xyz/software/hpcx-v1.9.5-gcc-inbox-redhat7.3-x86_64/mxm' '--disable-spawn' '--disable-ft-tests' '--enable-g=all' '--enable-nemesis-dbg-localoddeven' '--enable-large-tests' '--disable-perftest' 'CC=clang' 'CXX=clang++' 'FC=gfortran' 'F77=gfortran' --cache-file=/dev/null --disable-fortran
I think the issue is the evaluation of $PWD within the quotes. If you replace
./configure '--prefix=$PWD/BIN' ...
with
./configure --prefix=$PWD/BIN ...
you should be good.
I ran into this error as well when building a different piece of software. The solution for me was to enclose the shell variable in --prefix= with {}:
./configure --prefix=${PWD}/BIN
This is basically the same issue as in mingw ld cannot find some library which is exist in the search path, MinGW linker can't find MPICH2 libraries - and I'm aware that there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW - but I couldn't find anything that explains how I can troubleshoot.
I am building a project with a huge linker command like (via g++) on MinGW, in a MSYS2 shell (git-bash.exe). The process fails with, among others:
/z/path/to/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lssl
I add -Wl,--verbose to the g++ linker call (to be passed to ld), and I can see for the -L/z/path/to/libs/openssl/lib/mingw -lssl:
...
attempt to open /z/path/to/libs/openssl/lib/mingw/libssl.a failed
...
/z/path/to/libs/openssl/lib/mingw/ssl.dll failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
But this is weird, because the file exists?
$ file /z/path/to/libs/openssl/lib/mingw/libssl.a
/z/path/to/libs/openssl/lib/mingw/libssl.a: current ar archive
(... and it was built with the same compiler on the same machine)?
Weirdly, once it attempts to open with forward slash .../libssl.a, once with backslash ...\libssl.a - but at least the first path checks out in a bash shell, as shown above?
It gets even worse if I try to specify -l:libssl.a -- or if I specify -L/z/path/to/libs/openssl/lib/mingw -Wl,-Bstatic -lssl -- instead; then all attempts to open are with a backslash:
...
attempt to open /z/path/to/scripts/other/build/openssl/build/mingw/lib\libssl.a failed
attempt to open /z/path/to/libs/openssl/lib/mingw\libssl.a failed
...
To top it all off, if I look it up manually through the command line using ld, it is found ?!:
$ ld -L/z/path/to/libs/openssl/lib/mingw -lssl --verbose
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/ssl.dll.a failed
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
Does anyone have an idea why this happens, and how can I get ld to finally find these libraries? Or rather - how can I troubleshoot, and understand why these libraries are not found, when they exist at the paths where ld tries to open them?
OK, found something more - not sure if this is a bug; but my problem is that I'm actually reading arguments from a file (otherwise I get g++: Argument list too long). So, to simulate that:
$ echo " -Wl,--verbose -L/z/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
# nothing
$ g++ `cat tcmd3` 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
... it turns out, if the very same arguments are fed on the command line, then static library lookup succeeds - but if the arguments are read from file through the # at-sign, then static library lookup fails?! Unfortunately, I cannot use on my actual project, since even with cat, I'd still get g++: Argument list too long ... So how can I fix this?
MSYS has special handling of directories as arguments when they are used in the shell. This translates e.g. /<drive_letter>/blabla to the proper Windows style paths. This is to accomodate Unix programs that don't handle Z: style directory root.
What you see here is that MSYS isn't performing this interpretation for string read from a file. When you think about it, it's very logical, but as you have experienced first-hand, also sometimes annoying.
Long story short: don't put Unix style paths in files with command arguments. Instead, pass them through e.g. cygpath -w, which works in MSYS2 (which should be the MSYS that Git for Windows 2+ comes with).
Ok, with some more experiments, I noticed that:
-L/z/path/to/libs/openssl/lib/mingw, the Unix path specification, tends to fail - while if we specify the same, except starting with a Windows drive letter, that is:
-LZ:/path/to/libs/openssl/lib/mingw, then things work - also from an arguments file with # at-sign:
$ echo " -Wl,--verbose -LZ:/path/to/libs/openssl/lib/mingw -lssl -lcrypto " > tmcd3
$ g++ #tcmd3 2>&1 | grep succeeded | grep ssl
attempt to open Z:/path/to/libs/openssl/lib/mingw/libssl.a succeeded
attempt to open Z:/path/to/libs/openssl/lib/mingw/libcrypto.a succeeded
I guess, since the shell is MSYS2/git-bash.exe, entering full POSIX paths on the shell with /z/... is not a problem, because the shell will convert them - but in a file, there is nothing to convert them, so we must use Windows/MingW convention to specify them...
I'm using CMake 3.4.1, on Windows 10, with MSYS2 (everything up-to-date as of Dec. 25 2015).
When I use CMake's find_file command, it won't work unless the path is in Windows-style. This is a problem for me, because I'm trying to use findwxWidgets.cmake, which fails because of this.
For example:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
find_file(version_h version.h PATHS /mingw64/include/wx-3.0/wx)
message(STATUS "version_h: ${version_h}")
Running cmake spits out:
-- version_h: version_h-NOTFOUND
But it's clearly in there:
>>> file /mingw64/include/wx-3.0/wx/version.h
/mingw64/include/wx-3.0/wx/version.h: C source, ASCII text
I'm wondering if this is a bug, or if there's some obscure flag I have to set to get this to work. How do I get CMake's find_file to find files with UNIX-style paths?
MinGW-w64 cmake can't understand MSYS2 paths. You might propose a path transformation test program to the CMake developers, but that's fairly gross and I'd hope the would reject that. Instead these things must be solved case-by-case. wx-config, being a shell script, is providing an MSYS2 path.
This is a bug in the currently release MSYS2 wxWidgets packages that will be fixed in the next release. To work around it, find the line in /mingw64/bin/wx-config or /mingw32/bin/wx-config:
prefix=${input_option_prefix-${this_prefix:-/mingw64}}
(or /mingw32 of course) and add after it:
if [ "x${MSYSTEM}" = "xMINGW32" ] || [ "x${MSYSTEM}" = "xMINGW64" ]; then
prefix=$(cygpath -m ${prefix})
fi
Be careful to remove it at upgrade time though.
Trying to follow the instructions from here -- https://gorails.com/setup/osx/10.11-el-capitan -- to install Ruby on Rails, but I'm getting the following error:
➜ ~ rbenv install 2.2.3
Downloading ruby-2.2.3.tar.gz...
-> https://dqw8nmjcqpjn7.cloudfront.net/df795f2f99860745a416092a4004b016ccf77e8b82dec956b120f18bdc71edce
Installing ruby-2.2.3...
BUILD FAILED (OS X 10.11.2 using ruby-build 20150928)
Inspect or clean up the working tree at /var/folders/l3/skxhsvw51wz7fnn2v1v4d3sh0000gn/T/ruby-build.20151222232425.95349
Results logged to /var/folders/l3/skxhsvw51wz7fnn2v1v4d3sh0000gn/T/ruby-build.20151222232425.95349.log
Last 10 log lines:
checking for nroff... /usr/bin/nroff
.ext/include/x86_64-darwin15/ruby/config.h updated
ruby library version = 2.2.0
configure: creating ./config.status
config.status: creating GNUmakefile
awk: syntax error at source line 1 source file ./confyJCFwP/subs.awk
context is
>>> BEGIN <<< {
awk: bailing out at source line 275
config.status: error: could not create GNUmakefile
And then checking the log file, it says the same thing at the end:
...
.ext/include/x86_64-darwin15/ruby/config.h updated
ruby library version = 2.2.0
configure: creating ./config.status
config.status: creating GNUmakefile
awk: syntax error at source line 1 source file ./confyJCFwP/subs.awk
context is
>>> BEGIN <<< {
awk: bailing out at source line 275
config.status: error: could not create GNUmakefile
How can I fix this? I recently ran brew upgrade on everything and it seemed to complete successfully.
Note: I don't know if it's relevant but my shell is ZSH (via oh-my-zsh).
I ended up going through my PATH settings in ~/.zshrc and broke the entire path out into individual lines (there were a lot). I figured that way I could comment each PATH setting out individually if I thought it might matter. As it turns out, I was right. I commented out the following:
# export PATH="/usr/local/rvm/gems/ruby-2.1.0/bin:$PATH"
# export PATH="/usr/local/rvm/gems/ruby-2.1.0#global/bin:$PATH"
# export PATH="/usr/local/rvm/rubies/ruby-2.1.0/bin:$PATH"
# export PATH="/usr/local/rvm/gems/ruby-1.9.3-p448/bin:$PATH"
# export PATH="/usr/local/rvm/gems/ruby-1.9.3-p448#global/bin:$PATH"
# export PATH="/usr/local/rvm/rubies/ruby-1.9.3-p448/bin:$PATH"
I then re-ran the command and it completed successfully.
Hope this helps someone else.
When I try to build Assimp by running build_ios.sh, it tells me:
CMake Error: your C compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name.
CMake Error: your CXX compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
What I need the path to be is:
/Applications/XCode.app/Contents/Developer/Platforms/...
I've tried changing DEVROOT in build_ios.sh and IPHONE_xxxx_TOOLCHAIN.cmake, because that's what CMAKE_C_COMPILER etc seem to get generated from, but it still gives me the same errors.
Option 1:
You can set CMake variables at command line like this:
cmake -D CMAKE_C_COMPILER="/path/to/your/c/compiler/executable" -D CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable" /path/to/directory/containing/CMakeLists.txt
See this to learn how to create a CMake cache entry.
Option 2:
In your shell script build_ios.sh you can set environment variables CC and CXX to point to your C and C++ compiler executable respectively, example:
export CC=/path/to/your/c/compiler/executable
export CXX=/path/to/your/cpp/compiler/executable
cmake /path/to/directory/containing/CMakeLists.txt
Option 3:
Edit the CMakeLists.txt file of "Assimp": Add these lines at the top (must be added before you use project() or enable_language() command)
set(CMAKE_C_COMPILER "/path/to/your/c/compiler/executable")
set(CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable")
See this to learn how to use set command in CMake. Also this is a useful resource for understanding use of some of the common CMake variables.
Here is the relevant entry from the official FAQ: https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler
The cc and cxx is located inside /Applications/Xcode.app. This should find the right paths
export CXX=`xcrun -find c++`
export CC=`xcrun -find cc`
SOLUTIONS
Sometimes the project is created before installing g++. So install g++ first and then recreate your project. This worked for me.
Paste the following line in CMakeCache.txt:
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
Note the path to g++ depends on OS. I have used my fedora path obtained using which g++