master branch --- build problems
lfinsto at gwdg.de
lfinsto at gwdg.de
Thu Jul 29 15:36:08 CEST 2010
Hello,
After installing the most recent stable releases of autoconf, automake and
libtool:
autoconf (GNU Autoconf) 2.66
automake (GNU automake) 1.11.1
libtool (GNU libtool) 2.2.10
I had considerable difficulty getting the master branch to build, but I
finally succeeded, though I had to comment some things out, which isn't so
good.
The patch below contains the changes I had to make in existing files, but
that was only part of it.
In /lib/Makefile.am, I had to remove `po' from SUBDIRS. The error that I
got when it was included was this:
config.status: error: cannot find input file: `po/Makefile.in.in'
configure: error: ./configure failed for lib
There was no Makefile, Makefile.in or Makefile.in.in in this directory.
After `touch Makefile.in.in', the others were generated (they were empty).
However, later I got this error:
Making all in po
make[4]: Entering directory `/home/lfinsto/gnutls_dev/gnutls_master/lib/po'
make[4]: *** No rule to make target `all'. Stop.
Since I don't know that this is about, except that it seems to have
something to do with documentation, I just removed po from SUBDIRS.
In addition, I had to comment-out the calls to `AM_GNU_GETTEXT' in
`/lib/configure.ac'.
The `build-aux' directories were another problem. In order to generate
the needed files, I had to call `libtoolize' in the top build directory,
/lib/ and /libextra. Then aclocal with multiple `-I' options for the
various `m4' directories, autoconf, autoheader, automake --add-missing
--copy and configure in each of these directories. (Perhaps autoheader is
only necessary in the top build directory, I don't know.)
I had to correct the file permissions of the in `build-aux' directories by
hand, because they were not readable by the user. I don't know why this
should be so.
In /lib/m4/hooks.m4, I had to comment-out this macro invocation (as
mentioned previously):
+ #AC_CHECK_SIZEOF(void *)
Of course, I still needed to call
export LDFLAGS="-L/home/lfinsto/libgcrypt-1.4.6/lib"
even though I used
--with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6
since I haven't been able to solve this problem yet.
For more-or-less the same reason, this is still needed, too:
ln -s /home/lfinsto/libgcrypt-1.4.6/include/gcrypt.h /home/lfinsto
This is the error message I get without it:
/gnutls_dev/gnutlsmake[4]: Entering directory
`/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt'
CC init.lo
init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a
function)
make[4]: *** [init.lo] Error 1
make[4]: Leaving directory
`/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt'_master/lib/gcrypt/gcrypt.h
There a quite a few warnings like this:
gaa.skel:593: warning: call to 'fseek' declared with attribute warning:
fseek cannot handle files larger than 4 GB on 32-bit platforms - use
fseeko function for handling of large files
I suspect that they're not important, unless the files can be huge for
some reason.
Lots of warnings like this one:
serv.c:1163: warning: cast to pointer from integer of different size
It would probably be worthwhile going through and trying to get rid of
them. I've had a look, but it was a case of data types referring to other
data types and not obvious to an outsider what's going on.
The last problem was with the Guile bindings. I had to call `configure'
(in the top build directory) with the option `--disable-guile', because of
the following error, which occurred when `make install' was invoked (but
not previously when `make' was invoked):
libtool: install: (cd /home/lfinsto/gnutls_dev/gnutls_master/guile/src;
/bin/sh /home/lfinsto/gnutls_dev/gnutls_master/libtool --silent --tag CC
--mode=relink gcc -std=gnu99 -Wno-strict-prototypes -I../../lib/gl
-I../../lib/gl -pthread -g -O2 -L/home/lfinsto/libgcrypt-1.4.6/lib -o
libguile-gnutls-extra-v-1.la -rpath
/home/lfinsto/gnutls_dev/gnutls_master/lib
libguile_gnutls_extra_v_1_la-extra.lo ../../lib/libgnutls.la
../../libextra/libgnutls-extra.la ./libguile-gnutls-v-1.la
../../lib/gl/liblgnu.la -pthread -lguile -lltdl -L/usr/lib64 -lgmp -lcrypt
-lm -lltdl -ldl -lpthread )
libtool: relink: warning: `/usr/lib64/libltdl.la' seems to be moved
libtool: relink: warning: `/usr/lib64/libltdl.la' seems to be moved
/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/libltdl.a(libltdl_libltdl_la-ltdl.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/usr/lib64/libltdl.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
libtool: install: error: relink `libguile-gnutls-extra-v-1.la' with the
above command before installing it
make[4]: *** [install-libLTLIBRARIES] Error 1
make[4]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/guile/src'
Apparently, the Guile library was built with the old libltdl from the
OpenSuse RPM and I would need to rebuild it using the newer one I've
installed. However, I think I will just deinstall the Guile library and
get the most recent version of it.
Would you possibly consider checking `configure', the `Makefile.in' files,
the contents of the `build-aux' directories and other generated files into
the repository? That way one (with a bit of luck) could at least get the
version in the master branch to build without having to jump through too
many hoops.
I would also be interested to know what versions of autoconf, automake and
libtool you have installed on the systems you're using. I assume
everything works together smoothly on your systems.
One problem I ran into was these macro invocations in the top-level
configure.ac:
AC_LIBTOOL_WIN32_DLL
AC_PROG_LIBTOOL
This is from the libtool manual (for version 2.2.10):
-- Macro: LT_INIT (OPTIONS)
-- Macro: AC_PROG_LIBTOOL
-- Macro: AM_PROG_LIBTOOL
Add support for the `--enable-shared' and `--disable-shared'
`configure' flags.(1) `AC_PROG_LIBTOOL' and `AM_PROG_LIBTOOL' are
deprecated names for older versions of this macro; `autoupdate'
will upgrade your `configure.ac' files.
Before I installed libtool 2.2.10, I got an error because of
AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL. I didn't get an error when I
called LT_INIT, but the variable LIBTOOL wasn't defined and `configure'
failed, unless it was `make' --- unfortunately, I didn't save this error.
This, on the other hand, is from the Automake manual (version 1.11.1, 8
December 2009):
`AC_PROG_LIBTOOL'
Automake will turn on processing for `libtool' (*note
Introduction: (libtool)Top.).
LT_INIT isn't documented in this manual. So, it would seem that Autoconf,
Automake, and Libtool, or at least their most recent stable versions, are
not perfectly synchronized with respect to these macros and it was rather
frustrating trying to get `configure' and `make' to run, until it finally
occurred to me to install a newer version of libtool. However, since
AC_LIBTOOL_WIN32_DLL and AC_PROG_LIBTOOL are deprecated, I think it would
be better to use LT_INIT instead. I've made a note to myself to try this,
now that I've got the package to build.
Laurence
-------------------------------------------------------------
Laurence Finston
Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH
Am Fassberg 11
37077 Goettingen
Telefon: +49 551 201-1882
E-Mail: lfinsto at gwdg.de
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 13531d9..dc6ada3 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -23,7 +23,7 @@
ACLOCAL_AMFLAGS = -I m4 -I gl/m4
-SUBDIRS = gl po includes x509
+SUBDIRS = gl includes x509 #po
if ENABLE_MINITASN1
SUBDIRS += minitasn1
endif
diff --git a/lib/build-aux/config.rpath b/lib/build-aux/config.rpath
index c547c68..17298f2 100755
--- a/lib/build-aux/config.rpath
+++ b/lib/build-aux/config.rpath
@@ -2,7 +2,7 @@
# Output a system dependent set of variables, describing how to set the
# run time search path of shared libraries in an executable.
#
-# Copyright 1996-2007 Free Software Foundation, Inc.
+# Copyright 1996-2010 Free Software Foundation, Inc.
# Taken from GNU libtool, 2001
# Originally by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996
#
@@ -47,7 +47,7 @@ for cc_temp in $CC""; do
done
cc_basename=`echo "$cc_temp" | sed -e 's%^.*/%%'`
-# Code taken from libtool.m4's AC_LIBTOOL_PROG_COMPILER_PIC.
+# Code taken from libtool.m4's _LT_COMPILER_PIC.
wl=
if test "$GCC" = yes; then
@@ -64,7 +64,7 @@ else
;;
esac
;;
- mingw* | cygwin* | pw32* | os2*)
+ mingw* | cygwin* | pw32* | os2* | cegcc*)
;;
hpux9* | hpux10* | hpux11*)
wl='-Wl,'
@@ -76,7 +76,13 @@ else
;;
linux* | k*bsd*-gnu)
case $cc_basename in
- icc* | ecc*)
+ ecc*)
+ wl='-Wl,'
+ ;;
+ icc* | ifort*)
+ wl='-Wl,'
+ ;;
+ lf95*)
wl='-Wl,'
;;
pgcc | pgf77 | pgf90)
@@ -124,7 +130,7 @@ else
esac
fi
-# Code taken from libtool.m4's AC_LIBTOOL_PROG_LD_SHLIBS.
+# Code taken from libtool.m4's _LT_LINKER_SHLIBS.
hardcode_libdir_flag_spec=
hardcode_libdir_separator=
@@ -132,7 +138,7 @@ hardcode_direct=no
hardcode_minus_L=no
case "$host_os" in
- cygwin* | mingw* | pw32*)
+ cygwin* | mingw* | pw32* | cegcc*)
# FIXME: the MSVC++ port hasn't been tested in a loooong time
# When not using gcc, we currently assume that we are using
# Microsoft Visual C++.
@@ -158,7 +164,7 @@ if test "$with_gnu_ld" = yes; then
# option of GNU ld is called -rpath, not --rpath.
hardcode_libdir_flag_spec='${wl}-rpath ${wl}$libdir'
case "$host_os" in
- aix3* | aix4* | aix5*)
+ aix[3-9]*)
# On AIX/PPC, the GNU linker is very broken
if test "$host_cpu" != ia64; then
ld_shlibs=no
@@ -182,7 +188,7 @@ if test "$with_gnu_ld" = yes; then
ld_shlibs=no
fi
;;
- cygwin* | mingw* | pw32*)
+ cygwin* | mingw* | pw32* | cegcc*)
# hardcode_libdir_flag_spec is actually meaningless, as there is
# no search path for DLLs.
hardcode_libdir_flag_spec='-L$libdir'
@@ -254,7 +260,7 @@ else
hardcode_direct=unsupported
fi
;;
- aix4* | aix5*)
+ aix[4-9]*)
if test "$host_cpu" = ia64; then
# On IA64, the linker does run time linking by default, so we don't
# have to do anything special.
@@ -264,7 +270,7 @@ else
# Test if we are trying to use run time linking or normal
# AIX style linking. If -brtl is somewhere in LDFLAGS, we
# need to do runtime linking.
- case $host_os in aix4.[23]|aix4.[23].*|aix5*)
+ case $host_os in aix4.[23]|aix4.[23].*|aix[5-9]*)
for ld_flag in $LDFLAGS; do
if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl");
then
aix_use_runtimelinking=yes
@@ -326,7 +332,7 @@ else
;;
bsdi[45]*)
;;
- cygwin* | mingw* | pw32*)
+ cygwin* | mingw* | pw32* | cegcc*)
# When not using gcc, we currently assume that we are using
# Microsoft Visual C++.
# hardcode_libdir_flag_spec is actually meaningless, as there is
@@ -494,7 +500,7 @@ else
fi
# Check dynamic linker characteristics
-# Code taken from libtool.m4's AC_LIBTOOL_SYS_DYNAMIC_LINKER.
+# Code taken from libtool.m4's _LT_SYS_DYNAMIC_LINKER.
# Unlike libtool.m4, here we don't care about _all_ names of the library,
but
# only about the one the linker finds when passed -lNAME. This is the last
# element of library_names_spec in libtool.m4, or possibly two of them if
the
@@ -505,7 +511,7 @@ case "$host_os" in
aix3*)
library_names_spec='$libname.a'
;;
- aix4* | aix5*)
+ aix[4-9]*)
library_names_spec='$libname$shrext'
;;
amigaos*)
@@ -517,7 +523,7 @@ case "$host_os" in
bsdi[45]*)
library_names_spec='$libname$shrext'
;;
- cygwin* | mingw* | pw32*)
+ cygwin* | mingw* | pw32* | cegcc*)
shrext=.dll
library_names_spec='$libname.dll.a $libname.lib'
;;
diff --git a/lib/configure.ac b/lib/configure.ac
index 80dd99e..2fa2bc4 100644
--- a/lib/configure.ac
+++ b/lib/configure.ac
@@ -38,8 +38,8 @@ AC_PROG_LIBTOOL
LIBGNUTLS_HOOKS
-AM_GNU_GETTEXT([external])
-AM_GNU_GETTEXT_VERSION([0.17])
+#AM_GNU_GETTEXT([external])
+#AM_GNU_GETTEXT_VERSION([0.17])
AC_C_BIGENDIAN
diff --git a/lib/m4/hooks.m4 b/lib/m4/hooks.m4
index 86d7869..ada9d1d 100644
--- a/lib/m4/hooks.m4
+++ b/lib/m4/hooks.m4
@@ -304,7 +304,7 @@ AC_DEFUN([LIBGNUTLS_HOOKS],
# For storing integers in pointers without warnings
#
http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html#desc
- AC_CHECK_SIZEOF(void *)
+ #AC_CHECK_SIZEOF(void *)
AC_CHECK_SIZEOF(long)
AC_CHECK_SIZEOF(int)
case $ac_cv_sizeof_void_p in
More information about the Gnutls-devel
mailing list