Autotools for Fools: Debugging configure.in files via logging variables?
September 22, 2016 1:01 PM Subscribe
Is there a way to log or print-to-console the variables configure uses from a configure.in script? I'm trying to build Erlang on OS X 10.9 with ODBC, and the `--with-odbc` path that I'm providing seems to be ignored, possibly due to a bug in lib/odbc/configure.in. I know almost nothing about autotools, but I could test my theory if I could see what's in $host_os and $with_odbc in that context when configure runs. How can I do this?
To give some more background and messy details, the specific versions of Erlang I've tried building are 18.3 and 19.0. The first time I tried running configure I got back an error message:
Again:
A little more Googling pulled up this erlang-questions message, which called my attention to lib/odbc/configure.in, in particular lines 140-148, which appear to be where the configuration process checks to see if we're using OSX and if a `--with-odbc` path is given.
What I'd *like* to do at this point is add something to configure.in so that it will either print out or log both $host_os and $with_odbc. Naively, I tried adding:
Is there anything I can do to check these values?
(Also, if you know how to solve my Erlang build problem, that's welcome too, but I already have reasons why I'm reluctant to either "use homebrew/nix/fink/otherpackagemanager" or "upgrade to Yosemite and use the provided binary").
To give some more background and messy details, the specific versions of Erlang I've tried building are 18.3 and 19.0. The first time I tried running configure I got back an error message:
odbc : ODBC library - header check failedI went looking for any information I could find about ODBC libraries on OS X, and found a Stack Overflow question which suggested that Apple stopped including the iODBC SQL header files with OS X 10.9. So, I grabbed libiodbc, built the OS X version, installed it under /usr/local, and tried running `configure --with-odbc=/usr/local`.
Again:
odbc : ODBC library - header check failedO-kay. This is really mysterious, since I can verify that /usr/local/include contains a bunch of iodbc-related header files (iodbcext.h, iodbcunix.h, isqlext.h, sql.h, sqltypes.h, iodbcinst.h, isql.h, isqltypes.h, odbcinst.h, sqlext.h, sqlucode.h). But somehow, configure can't see them.
A little more Googling pulled up this erlang-questions message, which called my attention to lib/odbc/configure.in, in particular lines 140-148, which appear to be where the configuration process checks to see if we're using OSX and if a `--with-odbc` path is given.
What I'd *like* to do at this point is add something to configure.in so that it will either print out or log both $host_os and $with_odbc. Naively, I tried adding:
printf "%s\n" "blerg: $host_os"just above line 137, but this doesn't seem to do anything (at least, I can't find "blerg" successfully in the output or configure.log via use of ether grep or eyeballs). Not too surprising considering my shell-fu is weak, and I have little idea how autotools works.
echo >&1 "blerg: $with_odbc"
Is there anything I can do to check these values?
(Also, if you know how to solve my Erlang build problem, that's welcome too, but I already have reasons why I'm reluctant to either "use homebrew/nix/fink/otherpackagemanager" or "upgrade to Yosemite and use the provided binary").
Best answer: It looks like you didn't regenerate lib/odbc/configure after you changed lib/odbc/configure.in. Try running 'autoreconf' in lib/odbc/?
posted by plant at 3:13 PM on September 26, 2016 [1 favorite]
posted by plant at 3:13 PM on September 26, 2016 [1 favorite]
Response by poster: plant, that was the step I was missing in being able to print-debug the configure script (and verify that it was getting/deducing the correct path info). Thank you.
russm, appreciate your contribution too -- it didn't directly help me fix the build, but once I'd verified that the configure script was in fact getting the paths right, it did help me start thinking about the question of why the preprocessor/compiler might not see include paths... and it turns out that sometime by Mavericks, at least, Apple had set things up so that by default, clang does not search /usr/ and /usr/local.
Something about running xcode-select --install solves this problem (see this stack overflow question). I am more than a little curious as to what problem *not* searching these paths by default solves for Apple, since it's a pretty non-UNIX-y choice and certainly a break with the past.
If anyone reading this in the future finds themselves in a position where they need to check which paths clang is checking by default, you can use:
* clang -x c -v -E /dev/null to get include paths
* clang -Xlinker -v to get linker paths
(See this blog post for more about that and other situations in which it can be important.)
And to allow myself a little soapbox:
My first response would be "use macports or home-brew, whoever maintains the erlang port will already have solved these problems for you".
At least in theory, the same thing is true of the maintainers of the Erlang source or any source distribution where OS X is part of the official release. My general experience with package managers is that they're great (if you have a lot of room for just-to-be-sure dependencies) until they're not, and then you're left with an additional layer to troubleshoot in the process. In this case that intuition turned out to be correct; examining the SO question I linked above reveals that a lot of people were having the same problem with homebrew and other software because of this.
Anyway, my general rule of thumb is to *maybe* use package managers for desktop stuff and utilities that are meant for my machine and convenience only, but if we're talking about the piece of a stack I might be deploying to a production server, knowing how to build from source and being familiar with any issues is probably going to turn out to be helpful.
posted by weston at 2:02 PM on October 21, 2016
russm, appreciate your contribution too -- it didn't directly help me fix the build, but once I'd verified that the configure script was in fact getting the paths right, it did help me start thinking about the question of why the preprocessor/compiler might not see include paths... and it turns out that sometime by Mavericks, at least, Apple had set things up so that by default, clang does not search /usr/ and /usr/local.
Something about running xcode-select --install solves this problem (see this stack overflow question). I am more than a little curious as to what problem *not* searching these paths by default solves for Apple, since it's a pretty non-UNIX-y choice and certainly a break with the past.
If anyone reading this in the future finds themselves in a position where they need to check which paths clang is checking by default, you can use:
* clang -x c -v -E /dev/null to get include paths
* clang -Xlinker -v to get linker paths
(See this blog post for more about that and other situations in which it can be important.)
And to allow myself a little soapbox:
My first response would be "use macports or home-brew, whoever maintains the erlang port will already have solved these problems for you".
At least in theory, the same thing is true of the maintainers of the Erlang source or any source distribution where OS X is part of the official release. My general experience with package managers is that they're great (if you have a lot of room for just-to-be-sure dependencies) until they're not, and then you're left with an additional layer to troubleshoot in the process. In this case that intuition turned out to be correct; examining the SO question I linked above reveals that a lot of people were having the same problem with homebrew and other software because of this.
Anyway, my general rule of thumb is to *maybe* use package managers for desktop stuff and utilities that are meant for my machine and convenience only, but if we're talking about the piece of a stack I might be deploying to a production server, knowing how to build from source and being familiar with any issues is probably going to turn out to be helpful.
posted by weston at 2:02 PM on October 21, 2016
This thread is closed to new comments.
LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include configure --with-odbc
(in which case you also need to pass those env vars to make, "LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include make")
Though /usr/local should be in the standard search paths for the compiler, so I'm not sure why it's not already being picked up.
posted by russm at 5:11 PM on September 22, 2016 [1 favorite]