Discussion:
fail to build wmi-1.3.14
anctop
2013-09-06 04:26:17 UTC
Permalink
I'm trying to build openvas-libraries-6.0.0 from source, with wmi support.
Following the instructions in
"openvas-libraries-6.0.0/doc/wmi-howto.txt", I downloaded the wmi
distribution, unpacked it, applied the two patches, cd to
"Samba/source" and run "autogen.sh", then "sh ./configure" and "make
proto all", but failed.

My system is running linux kernel 3.8.8, environment has :
binutils-2.21.1 ; gcc-4.4.6 ; glibc-2.13 ; make-3.82 ;
cmake-2.8.11.2 ; pkg-config-0.28 ; nettle-2.6 ;
gnutls-3.1.5 ; libffi-3.0.13 ; Python-2.6.8 ;
gettext-0.18.2.1 ; glib-2.34.0 ; openssl-1.0.1e ;
libssh-0.5.3 ; libpcap-1.3.0 ; libgpg-error-1.12 ;
libgcrypt-1.5.3 ; libassuan-2.1.1 ; libksba-1.3.0 ;
pth-2.0.7 ; gnupg-2.0.21 ; gpgme-1.4.2

The "configure" script was completed with the info :
Support for GTK+ frontends: no (install gtk,gconf)
Support for SSL in SWAT and LDAP: yes
Support for threads in smbd (see --with-pthread): no (install PTHREAD)
Support for intelligent command line editing: no (install READLINE)
Support for changing process titles (see --with-setproctitle): no
(install SETPROCTITLE)
Support for using extended attributes: yes
Support for using libblkid: yes
Support for using iconv: yes
Support for using pam: no (install PAM)
Using external popt: no
Developer mode: no
Automatic dependencies: no (install GNU make >= 3.81 and see
--enable-automatic-dependencies)
Building shared libraries: yes
Using shared libraries internally: no (specify --enable-dso)

However, "make proto all" was failed :
Compiling lib/registry/tools/regpatch.c
Linking bin/regpatch
bin/static/libtls.a(tls.o): In function `tls_init_server':
tls.c:(.text+0x1289): undefined reference to `gnutls_transport_set_lowat'
bin/static/libtls.a(tls.o): In function `tls_init_client':
tls.c:(.text+0x16a6): undefined reference to `gnutls_transport_set_lowat'
collect2: ld returned 1 exit status
make: *** [bin/regpatch] Error 1

It appears to be a problem with "gnutls", but other versions (3.0.x)
do not help.
Jan-Oliver Wagner
2013-10-15 17:01:10 UTC
Permalink
Post by anctop
I'm trying to build openvas-libraries-6.0.0 from source, with wmi support.
Following the instructions in
"openvas-libraries-6.0.0/doc/wmi-howto.txt", I downloaded the wmi
distribution, unpacked it, applied the two patches, cd to
"Samba/source" and run "autogen.sh", then "sh ./configure" and "make
proto all", but failed.
...
It appears to be a problem with "gnutls", but other versions (3.0.x)
do not help.
I recommend to make a quick research about gnutls_transport_set_lowat.

With Debian 6 and 7 I have not experienced such problems.
--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
anctop
2013-10-16 03:16:54 UTC
Permalink
Thank you for the hint.

The GNU TLS manual says that from v.3.0.3 "gnutls_transport_set_lowat"
is deprecated, but the file "tls.c" in
"wmi-1.3.14/Samba/source/lib/tls" still uses it.

I find that the problem can be solved by replacing occurrences of
"gnutls_transport_set_lowat(tls->session, 0);" by
"gnutls_record_check_pending(tls->session);" before running
"./autogen.sh".
Post by Jan-Oliver Wagner
Post by anctop
I'm trying to build openvas-libraries-6.0.0 from source, with wmi support.
Following the instructions in
"openvas-libraries-6.0.0/doc/wmi-howto.txt", I downloaded the wmi
distribution, unpacked it, applied the two patches, cd to
"Samba/source" and run "autogen.sh", then "sh ./configure" and "make
proto all", but failed.
...
It appears to be a problem with "gnutls", but other versions (3.0.x)
do not help.
I recommend to make a quick research about gnutls_transport_set_lowat.
With Debian 6 and 7 I have not experienced such problems.
--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
Loading...