I'm trying to build lsh on a Solaris 2.6 system using gcc 2.95.3. I've worked around a number of minor issues (no asprintf for building nettle examples, among other things) but now find myself stuck trying to configure lsh itself. Here is my configure command line...
./configure --prefix=/opt/lsh
--with-include-path=/opt/gmp/include:/opt/nettle/include:/opt/liboop/include --with-lib-path=/opt/gmp/lib:/opt/nettle/lib:/opt/liboop/lib
... and it always fails here...
checking whether byte ordering is bigendian... yes checking for short... yes checking size of short... configure: error: cannot compute sizeof (short), 77
Is this a known issue with a quick fix?
Pete Naylor pete@geckoworks.com writes:
Here is my configure command line...
./configure --prefix=/opt/lsh
--with-include-path=/opt/gmp/include:/opt/nettle/include:/opt/liboop/include --with-lib-path=/opt/gmp/lib:/opt/nettle/lib:/opt/liboop/lib
... and it always fails here...
checking whether byte ordering is bigendian... yes checking for short... yes checking size of short... configure: error: cannot compute sizeof (short), 77
That kind of error usually indicates some severe problem with the build environment and compiler (or the configure script's detection thereof).
You have to check config.log for the compiler command line, test program and error messages.
Regards, /Niels
Niels Möller wrote...
You have to check config.log for the compiler command line, test program and error messages.
Much thanks - this led me to the realization that the runtime linker wasn't able to find liboop when configure was calling conftest. Seems that GNU autoconf doesn't necessarily deal with shared libraries very well in Solaris. I dropped the library and include path options to configure and instead put all that info in my LDFLAGS and CPPFLAGS environment variables - no more problems. I subsequently found this suggestion somewhere in the documentation - sorry for bothering the list.
Pete Naylor pete@geckoworks.com writes:
Much thanks - this led me to the realization that the runtime linker wasn't able to find liboop when configure was calling conftest. Seems that GNU autoconf doesn't necessarily deal with shared libraries very well in Solaris. I dropped the library and include path options to configure and instead put all that info in my LDFLAGS and CPPFLAGS environment variables - no more problems. I subsequently found this suggestion somewhere in the documentation - sorry for bothering the list.
What did you pass to configure that didn't work as you expected? It is quite possible that it's to be considered as a bug in the configure script.
/Pontus
Pete Naylor pete@geckoworks.com writes:
Much thanks - this led me to the realization that the runtime linker wasn't able to find liboop when configure was calling conftest. Seems that GNU autoconf doesn't necessarily deal with shared libraries very well in Solaris.
autoconf doesn't know much about -R flags. However, lsh's configure script tries to figure it out. First, it adds -L-flags from your --with-lib-path argument, and puts the directories on the RPATH_CANDIDATE_DIRS list. It also looks at uname to figure out what the "-R"-flag is called on your system. Next, from configure.ac:
AC_CHECK_LIB([oop], [oop_sys_new],, [AC_MSG_ERROR([liboop is missing. Get liboop from http://www.liboop.org])])
LSH_RPATH_FIX
The first macro expands into a linking test, and adds an -l flag. The next macro tries do compile and run a dummy test program, and if that fails (typically because the new -l flag made the linker link the test program with some library that isn't found at runtime), it tries to add -R options from using the directories in RPATH_CANDIDATE_DIRS.
These tricks have worked for me (on Solaris), so if it doesn't work for you I'd like to see a full bug report, including the config.log.
I dropped the library and include path options to configure and instead put all that info in my LDFLAGS and CPPFLAGS environment variables - no more problems.
If you know exactly what your doing, setting those variables directly is the most robust way. However, it's better to put them on configure's command line,
./configure LDFLAGS=...
rather than
LDFLAGS=... ./configure
because otherwise they will be lost whenever configure is rerun, typically by ./config.status --recheck is run. (Variables on the command line are supported since autoconf 2.5something, it won't work with configurescripts created by autoconf-2.13).
Regards, /Niels
nisse@lysator.liu.se (Niels Möller) writes:
If you know exactly what your doing, setting those variables directly is the most robust way. However, it's better to put them on configure's command line,
./configure LDFLAGS=...
rather than
LDFLAGS=... ./configure
because otherwise they will be lost whenever configure is rerun, typically by ./config.status --recheck is run. (Variables on the command line are supported since autoconf 2.5something, it won't work with configurescripts created by autoconf-2.13).
<nitpick-mode>
Actually, for variables declared as precious (using AC_ARG_VAR or automatic, as is the case for CFLAGS, CPPFLAGS, LDFLAGD, CC et cetera, IIRC), that is handled automatically nowadays, so it doesn't matter whatever one does ./configure LDFLAGS=... or LDFLAGS=... ./configure. Still, the recommended way is to pass to pass parameters as flags (e.g. ./configure LDFLAGS=...).
</nitpick-mode>
/Pontus
Niels Möller wrote...
These tricks have worked for me (on Solaris), so if it doesn't work for you I'd like to see a full bug report, including the config.log.
I wonder if maybe you install all your optional libraries and includes under the same directory - /usr/local perhaps. I install each such package under its own directory such as /opt/gmp, /opt/liboop, /opt/nettle. The runtime linker would already search the right place for liboop due to -R paths from nettle and gmp. Just a guess.
When I remove all my build-related environment variables, and run configure as follows...
./configure --prefix=/opt/lsh
--with-include-path=/opt/gmp/include:/opt/nettle/include:/opt/liboop/include --with-lib-path=/opt/gmp/lib:/opt/nettle/lib:/opt/liboop/lib
... the configure script fails here...
checking whether byte ordering is bigendian... yes checking for short... yes checking size of short... configure: error: cannot compute sizeof (short), 77
... and config.log indicates that it's because the conftest binary cannot be executed because the runtime linker cannot find liboop. I'll email my config.log to you off-list since it's rather large.
This is Solaris 2.6 with GCC 2.95.3. Thanks for your help!