From marlam at marlam.de  Mon Mar  3 20:44:26 2008
From: marlam at marlam.de (Martin Lambers)
Date: Mon, 3 Mar 2008 20:44:26 +0100
Subject: [Help-gnutls] Performance of gnutls_record_recv(session, &c, 1)?
Message-ID: <20080303194426.GA7280@wile.lambers.home>

Hi all,

Dimitrios Apostolou reported a large performance difference between the
OpenSSL and GnuTLS versions of mpop, a POP3 client, when querying the
status of a large POP3 mail box (>70000 messages).

In this situation, mpop needs to read a large amount of data (size
listings and UIDs, but not the mails itself). This takes 1m15s with
GnuTLS and only about 15s with OpenSSL. The 1m15s are completely spent
at 100% CPU.

Mpop uses gnutls_record_recv(session, &c, 1) for reading the data, i.e.
it reads the characters one at a time. It does not do any buffering
because the TLS library needs to do buffering internally anyway.
The OpenSSL variant of mpop does the equivalent: SSL_read(ssl, &c, 1).

Can this performance difference be caused by different TLS session
parameters? If so, which parameters would that be? 
Should mpop perform additional buffering and read larger chunks of data
with gnutls_record_recv()?

Regards,
Martin




From nmav at gnutls.org  Wed Mar  5 19:31:31 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 05 Mar 2008 20:31:31 +0200
Subject: [Help-gnutls] Performance of gnutls_record_recv(session, &c, 1)?
In-Reply-To: <20080303194426.GA7280@wile.lambers.home>
References: <20080303194426.GA7280@wile.lambers.home>
Message-ID: <47CEE703.1050709@gnutls.org>

Martin Lambers wrote:
> Hi all,
> 
> Dimitrios Apostolou reported a large performance difference between the
> OpenSSL and GnuTLS versions of mpop, a POP3 client, when querying the
> status of a large POP3 mail box (>70000 messages).
> 
> In this situation, mpop needs to read a large amount of data (size
> listings and UIDs, but not the mails itself). This takes 1m15s with
> GnuTLS and only about 15s with OpenSSL. The 1m15s are completely spent
> at 100% CPU.
> 
> Mpop uses gnutls_record_recv(session, &c, 1) for reading the data, i.e.
> it reads the characters one at a time. It does not do any buffering
> because the TLS library needs to do buffering internally anyway.
> The OpenSSL variant of mpop does the equivalent: SSL_read(ssl, &c, 1).
> 
> Can this performance difference be caused by different TLS session
> parameters? If so, which parameters would that be? 
> Should mpop perform additional buffering and read larger chunks of data
> with gnutls_record_recv()?

Indeed gnutls_record_recv wasn't written for 1 byte reads. Currently it 
has quite an overhead for reading few bytes.

regards,
Nikos




From simon at josefsson.org  Thu Mar  6 12:32:09 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 06 Mar 2008 12:32:09 +0100
Subject: [Help-gnutls] 
	Re: Performance of gnutls_record_recv(session, &c, 1)?
In-Reply-To: <47CEE703.1050709@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Wed, 05 Mar 2008 20:31:31 +0200")
References: <20080303194426.GA7280@wile.lambers.home>
	<47CEE703.1050709@gnutls.org>
Message-ID: <8763w05bra.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Martin Lambers wrote:
>> Hi all,
>>
>> Dimitrios Apostolou reported a large performance difference between the
>> OpenSSL and GnuTLS versions of mpop, a POP3 client, when querying the
>> status of a large POP3 mail box (>70000 messages).
>>
>> In this situation, mpop needs to read a large amount of data (size
>> listings and UIDs, but not the mails itself). This takes 1m15s with
>> GnuTLS and only about 15s with OpenSSL. The 1m15s are completely spent
>> at 100% CPU.
>>
>> Mpop uses gnutls_record_recv(session, &c, 1) for reading the data, i.e.
>> it reads the characters one at a time. It does not do any buffering
>> because the TLS library needs to do buffering internally anyway.
>> The OpenSSL variant of mpop does the equivalent: SSL_read(ssl, &c, 1).
>>
>> Can this performance difference be caused by different TLS session
>> parameters? If so, which parameters would that be? Should mpop
>> perform additional buffering and read larger chunks of data
>> with gnutls_record_recv()?
>
> Indeed gnutls_record_recv wasn't written for 1 byte reads. Currently
> it has quite an overhead for reading few bytes.

I've added a ticket for this:

http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/19

This could be one sub-project when we start to optimize things.  Before
I start optimize things personally, I'd like to have more benchmark data
available so that we know I attack the important parts.  If someone else
would like to solve this particular problem now, that would be very
useful.  I don't think it is difficult to solve, it should be easy to
reproduce and profile.

/Simon




From simon at josefsson.org  Tue Mar 11 16:49:36 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Mar 2008 16:49:36 +0100
Subject: [Help-gnutls] Re: Unable to make gnutls in HPUX
In-Reply-To: <922d0b4d0802180406i12d8ca07ldf6240e984f97490@mail.gmail.com>
	(Haidar Habib's message of "Mon, 18 Feb 2008 17:36:14 +0530")
References: <922d0b4d0802150309h4d448b12u256daee7461f8f4e@mail.gmail.com>
	<87wsp2tsrl.fsf@mocca.josefsson.org>
	<922d0b4d0802180406i12d8ca07ldf6240e984f97490@mail.gmail.com>
Message-ID: <87ve3tjm5r.fsf@mocca.josefsson.org>

"Haidar Habib" <h.habib at gmail.com> writes:

> Hi Simon,
>
> Actually my application is written in C++ so I think C++ library is needed.
>
> As suggested by someone I included CXX=aCC also at configure time and
> now I got the following errors.
>
> I have also included output of ./configure and config.log files.

Thanks.  It seems there is something wrong with either the C++ compiler
or our C++ code.  I don't know C++ well enough to support our C++
bindings.  Nikos, do you have any ideas?  If anyone else knows C++ and
can explain the error messages, that would be appreciated.

/Simon

> Error 19: "../includes/gnutls/gnutlsxx.h", line 10 # Unexpected 'std'.
>     class exception: public std::exception
>                             ^^^
> Error 19: "../includes/gnutls/gnutlsxx.h", line 179 # Unexpected 'std'.
>             bool get_peers_certificate(std::vector<gnutls_datum_t>
> &out_certs) const;
>                                        ^^^
> Error 19: "gnutlsxx.cpp", line 237 # Unexpected 'std'.
>     bool session::get_peers_certificate(std::vector<gnutls_datum_t>
> &out_certs) const
>                                         ^^^
> Error 698: Exact position unknown; near ["/opt/aCC/include/exception",
> line 46]. # The declarations class exception and class exception are
> both visible and neither is preferred under the name lookup rules.
> Error 698: Exact position unknown; near ["/opt/aCC/include/exception",
> line 46]. # The declarations class exception and class exception are
> both visible and neither is preferred under the name lookup rules.
> Error 221: "gnutlsxx.cpp", line 845 # Member 'get_code' not declared
> in class exception ["/opt/aCC/include/exception", line 53].
>     int exception::get_code()
>                    ^^^^^^^^
> Error 172: "gnutlsxx.cpp", line 847 # Undeclared variable 'retcode'.
>         return retcode;
>                ^^^^^^^
> Error 698: Exact position unknown; near ["/opt/aCC/include/exception",
> line 46]. # The declarations class exception and class exception are
> both visible and neither is preferred under the name lookup rules.
> Error 174: "gnutlsxx.cpp", line 850 # Function redefinition;
> previously defined as "const char *exception::what() const" at
> ["/opt/aCC/include/exception", line 59].
>     const char* exception::what() const throw()
>                            ^^^^
> Error 445: "gnutlsxx.cpp", line 850 # Cannot recover from earlier errors.
>     const char* exception::what() const throw()
>
>
> On Feb 18, 2008 4:51 PM, Simon Josefsson <simon at josefsson.org> wrote:
>>
>> "Haidar Habib" <h.habib at gmail.com> writes:
>>
>> > Hi,
>> >
>> > I am trying to build gnutls-1.6.3 in HP-UX , but when i am running
>> > make command after ./configure it showing following errors.
>> >
>> > g++: +b: No such file or directory
>> > g++: /saurabh/gnutls-1.6.3/lib/.libs:/usr/local/lib: No such file or directory
>> >
>> > I am makeing from /saurabh/gnutls-1.6.3 directory and used configure
>> > with following options
>> >
>> > ./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext
>> > -Wl,+s -g" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"
>>
>> If you don't need the C++ library, try adding --disable-cxx when running
>> ./configure.
>>
>> Otherwise, please send the output from running ./configure, and the
>> contents of the config.log file.
>>
>> /Simon
>>
>
>
>
> On Feb 18, 2008 4:51 PM, Simon Josefsson <simon at josefsson.org> wrote:
>>
>> "Haidar Habib" <h.habib at gmail.com> writes:
>>
>> > Hi,
>> >
>> > I am trying to build gnutls-1.6.3 in HP-UX , but when i am running
>> > make command after ./configure it showing following errors.
>> >
>> > g++: +b: No such file or directory
>> > g++: /saurabh/gnutls-1.6.3/lib/.libs:/usr/local/lib: No such file or directory
>> >
>> > I am makeing from /saurabh/gnutls-1.6.3 directory and used configure
>> > with following options
>> >
>> > ./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext
>> > -Wl,+s -g" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"
>>
>> If you don't need the C++ library, try adding --disable-cxx when running
>> ./configure.
>>
>> Otherwise, please send the output from running ./configure, and the
>> contents of the config.log file.
>>
>> /Simon
>>
>
>
>
> -- 
> With regards,
> Md. Haidar Habib
> Senior Software Engineer
> haidar.habib at aricent.com
> Aricent
> Gurgaon
> Cell- 09350042332
> [JOSH]/saurabh/gnutls-1.6.3>./configure CC=aCC CFLAGS="+d -Aa +DAportable -mt +W930 +W829 +Z -ext -Wl,+s -g" CXX=aCC CXXCPP="aCC -E" LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib/"
> checking build system type... hppa64-hp-hpux11.11
> checking host system type... hppa64-hp-hpux11.11
> checking target system type... hppa64-hp-hpux11.11
> checking for a BSD-compatible install... /opt/imake/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... ./install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> configure: autobuild project... gnutls
> configure: autobuild revision... 1.6.3
> configure: autobuild hostname... JOSH
> configure: autobuild timestamp... 20080218-164630
> checking whether in dmalloc mode... no
> checking whether in electric fence mode... no
> checking whether in developer mode... no
> checking whether in profile mode... no
> ***
> *** Checking for compilation programs...
>
> checking whether NLS is requested... yes
> checking for msgfmt... /opt/gnome/bin/msgfmt
> checking for gmsgfmt... /opt/gnome/bin/msgfmt
> checking for xgettext... no
> checking for msgmerge... no
> checking for style of include used by make... GNU
> checking for gcc... aCC
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... no
> checking whether aCC accepts -g... yes
> checking for aCC option to accept ISO C89... -Ae
> checking dependency style of aCC -Ae... hp2
> checking for non-GNU ld... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... no
> checking for shared library run path origin... done
> checking for CFPreferencesCopyAppValue... no
> checking for CFLocaleCopyCurrent... no
> checking whether NLS is requested... yes
> checking for GNU gettext in libc... no
> checking for iconv... yes
> checking for GNU gettext in libintl... no
> checking whether to use NLS... no
> checking for gcc... (cached) aCC
> checking whether we are using the GNU C compiler... (cached) no
> checking whether aCC accepts -g... (cached) yes
> checking for aCC option to accept ISO C89... (cached) -Ae
> checking dependency style of aCC -Ae... (cached) hp2
> checking whether we are using the GNU C++ compiler... no
> checking whether aCC accepts -g... yes
> checking dependency style of aCC... hp2
> checking whether ln -s works... yes
> ***
> *** Detecting compiler options...
>
> checking for ranlib... ranlib
> checking for an ANSI C-conforming const... yes
> checking for inline... __inline
> checking whether to build C++ library... yes
> checking whether C99 macros are supported... yes
> ***
> *** Detecting C library capabilities...
>
> checking how to run the C preprocessor... aCC -Ae -E
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for ANSI C header files... yes
> checking whether time.h and sys/time.h may both be included... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... no
> checking for unistd.h... yes
> checking for strings.h... (cached) yes
> checking alloca.h usability... yes
> checking alloca.h presence... yes
> checking for alloca.h... yes
> checking errno.h usability... yes
> checking errno.h presence... yes
> checking for errno.h... yes
> checking sys/time.h usability... yes
> checking sys/time.h presence... yes
> checking for sys/time.h... yes
> checking time.h usability... yes
> checking time.h presence... yes
> checking for time.h... yes
> checking math.h usability... yes
> checking math.h presence... yes
> checking for math.h... yes
> checking limits.h usability... yes
> checking limits.h presence... yes
> checking for limits.h... yes
> checking float.h usability... yes
> checking float.h presence... yes
> checking for float.h... yes
> checking stdarg.h usability... yes
> checking stdarg.h presence... yes
> checking for stdarg.h... yes
> checking ctype.h usability... yes
> checking ctype.h presence... yes
> checking for ctype.h... yes
> checking netdb.h usability... yes
> checking netdb.h presence... yes
> checking for netdb.h... yes
> checking for umask... yes
> checking for vasprintf... no
> checking for isascii... yes
> checking for gmtime_r... yes
> checking for fork... yes
> checking for working alloca.h... yes
> checking for alloca... yes
> ***
> *** Detecting system's parameters...
>
> checking for valgrind... no
> checking whether self tests are run under valgrind... no
> checking for unsigned long... yes
> checking size of unsigned long... 4
> checking for unsigned int... yes
> checking size of unsigned int... 4
> checking for void *... yes
> checking size of void *... 4
> checking for long... yes
> checking size of long... 4
> checking for int... yes
> checking size of int... 4
> checking for uint... yes
> checking for ssize_t... yes
> checking whether byte ordering is bigendian... yes
> ***
> *** Checking for external libraries...
>
> checking for libgcrypt-config... /usr/local/bin/libgcrypt-config
> checking for LIBGCRYPT - version >= 1.2.2... yes
> checking LIBGCRYPT API version... okay
> checking whether to disable SRP authentication support... no
> checking whether to disable PSK authentication support... no
> checking whether to disable anonymous authentication support... no
> checking whether to disable extra PKI stuff... no
> checking whether to disable OpenPGP Certificate authentication support... no
> checking for opencdk-config... no
> checking for libopencdk - version >= 0.5.5... no
> *** The opencdk-config script installed by LIBOPENCDK could not be found
> *** If LIBOPENCDK was installed in PREFIX, make sure PREFIX/bin is in
> *** your path, or set the LIBOPENCDK_CONFIG environment variable to the
> *** full path to opencdk-config.
> configure: WARNING:
> ***
> *** libopencdk 0.5.5 was not found. You may want to get it from
> *** ftp://ftp.gnutls.org/pub/gnutls/opencdk/
> ***
> *** Will use the included opencdk.
> ***
>
> checking whether to use the included opencdk... yes
> checking whether to disable OpenSSL compatibility layer... no
> checking for libtasn1-config... no
> checking for libtasn1 - version >= 0.3.4... no
> *** The libtasn1-config script installed by LIBTASN1 could not be found
> *** If LIBTASN1 was installed in PREFIX, make sure PREFIX/bin is in
> *** your path, or set the LIBTASN1_CONFIG environment variable to the
> *** full path to libtasn1-config.
> configure: WARNING:
> ***
> *** LibtASN1 0.3.4 was not found. Will use the included one.
>
> checking whether to use the included minitasn1... yes
> checking for cfg_get_context in -lcfg+... no
> configure: WARNING:
> ***
> *** Libcfg+ was not found. Will use the included one.
> checking whether to use the included libcfg... yes
> checking whether to include zlib compression support... yes
> checking for libz... no
> configure: WARNING: ***
> *** ZLIB was not found. You will not be able to use ZLIB compression.
> checking whether to include lzo compression support... yes
> checking whether to use the included lzo compression library... no
> checking for lzo1x_1_compress in -llzo2... no
> checking for lzo1x_1_compress in -llzo... no
> configure: WARNING: ***
> *** Could not find liblzo or liblzo2. Will use the included minilzo.
>
> checking for ptrdiff_t... yes
> checking for size_t... yes
> checking for short... yes
> checking size of short... 2
> checking for int... (cached) yes
> checking size of int... (cached) 4
> checking for long... (cached) yes
> checking size of long... (cached) 4
> checking for long long... yes
> checking size of long long... 8
> checking for __int64... no
> checking size of __int64... 0
> checking for void *... (cached) yes
> checking size of void *... (cached) 4
> checking for size_t... (cached) yes
> checking size of size_t... 4
> checking for ptrdiff_t... (cached) yes
> checking size of ptrdiff_t... 4
> checking for an ANSI C-conforming const... (cached) yes
> checking for memcmp... yes
> checking for memcpy... yes
> checking for memmove... yes
> checking for memset... yes
> ***
> *** Setting up gnulib compatibility files...
>
> checking arpa/inet.h usability... yes
> checking arpa/inet.h presence... yes
> checking for arpa/inet.h... yes
> checking sys/socket.h usability... yes
> checking sys/socket.h presence... yes
> checking for sys/socket.h... yes
> checking netinet/in.h usability... yes
> checking netinet/in.h presence... yes
> checking for netinet/in.h... yes
> checking for netdb.h... (cached) yes
> checking stdio_ext.h usability... no
> checking stdio_ext.h presence... no
> checking for stdio_ext.h... no
> checking termios.h usability... yes
> checking termios.h presence... yes
> checking for termios.h... yes
> checking wchar.h usability... yes
> checking wchar.h presence... yes
> checking for wchar.h... yes
> checking for stdint.h... (cached) no
> checking for sys/stat.h... (cached) yes
> checking for C/C++ restrict keyword... __restrict
> checking for IPv4 sockets... yes
> checking for IPv6 sockets... yes
> checking whether getdelim is declared... no
> checking whether getpass is declared... yes
> checking for __fsetlocking... no
> checking for tcgetattr... yes
> checking for tcsetattr... yes
> checking for lstat... yes
> checking whether fflush_unlocked is declared... no
> checking whether flockfile is declared... yes
> checking whether fputs_unlocked is declared... no
> checking whether funlockfile is declared... yes
> checking whether putc_unlocked is declared... yes
> checking for off_t... yes
> checking for stdbool.h that conforms to C99... no
> checking for _Bool... yes
> checking for long long int... yes
> checking for unsigned long long int... yes
> checking whether strdup is declared... yes
> configure: checking how to do getaddrinfo, freeaddrinfo and getnameinfo
> checking for library containing getaddrinfo... no
> checking for getaddrinfo... no
> checking for getaddrinfo in ws2tcpip.h and -lws2_32... no
> checking for gai_strerror... no
> checking for library containing gethostbyname... none required
> checking for library containing getservbyname... none required
> checking for gethostbyname... yes
> checking whether getaddrinfo is declared... no
> checking whether freeaddrinfo is declared... no
> checking whether gai_strerror is declared... no
> checking whether getnameinfo is declared... no
> checking for struct addrinfo... no
> checking for getdelim... no
> checking for flockfile... yes
> checking for funlockfile... yes
> checking whether getline is declared... no
> checking for getline... no
> checking for getdelim... (cached) no
> checking for flockfile... (cached) yes
> checking for funlockfile... (cached) yes
> checking for getpass... yes
> checking for inet_ntop... yes
> checking whether inet_ntop is declared... yes
> checking for inet_pton... yes
> checking whether inet_pton is declared... yes
> checking for readline... no
> checking readline/readline.h usability... no
> checking readline/readline.h presence... no
> checking for readline/readline.h... no
> checking for socklen_t... yes
> checking sys/inttypes.h usability... no
> checking sys/inttypes.h presence... no
> checking for sys/inttypes.h... no
> checking sys/bitypes.h usability... no
> checking sys/bitypes.h presence... no
> checking for sys/bitypes.h... no
> checking for bit size of ptrdiff_t... 32
> checking for bit size of sig_atomic_t... 32
> checking for bit size of size_t... 32
> checking for bit size of wchar_t... 32
> checking for bit size of wint_t... 32
> checking whether sig_atomic_t is signed... no
> checking whether wchar_t is signed... no
> checking whether wint_t is signed... no
> checking for ptrdiff_t integer literal suffix... l
> checking for sig_atomic_t integer literal suffix... u
> checking for size_t integer literal suffix... ul
> checking for wchar_t integer literal suffix... u
> checking for wint_t integer literal suffix... u
> checking for strdup... yes
> checking whether memmem is declared... no
> checking whether <limits.h> defines MIN and MAX... yes
> checking whether <sys/param.h> defines MIN and MAX... yes
> checking whether snprintf is declared... yes
> checking whether stat file-mode macros are broken... no
> checking for EOVERFLOW... yes
> checking for long double... yes
> checking for wchar_t... yes
> checking for wint_t... yes
> checking for inttypes.h... yes
> checking for stdint.h... no
> checking for long long... (cached) yes
> checking for intmax_t... yes
> checking device with (strong) random data...... /dev/random
> checking device with pseudo random data...... /dev/urandom
> checking device with unpredictable data for nonces...... /dev/urandom
> checking for /dev/random... no
> configure: WARNING: Device `/dev/random' does not exist, consider to use --enable-random-device
> checking for /dev/urandom... no
> configure: WARNING: Device `/dev/urandom' does not exist, consider to use --enable-pseudo-random-device
> checking for /dev/urandom... (cached) no
> configure: WARNING: Device `/dev/urandom' does not exist, consider to use --enable-nonce-device
> checking for memmem... no
> checking for memmove... (cached) yes
> checking for stdint.h... (cached) no
> checking for SIZE_MAX... 4294967295UL
> checking for snprintf... yes
> checking for socklen_t... (cached) yes
> checking for sys/inttypes.h... (cached) no
> checking for sys/bitypes.h... (cached) no
> checking for bit size of ptrdiff_t... (cached) 32
> checking for bit size of sig_atomic_t... (cached) 32
> checking for bit size of size_t... (cached) 32
> checking for bit size of wchar_t... (cached) 32
> checking for bit size of wint_t... (cached) 32
> checking whether sig_atomic_t is signed... (cached) no
> checking whether wchar_t is signed... (cached) no
> checking whether wint_t is signed... (cached) no
> checking for ptrdiff_t integer literal suffix... (cached) l
> checking for sig_atomic_t integer literal suffix... (cached) u
> checking for size_t integer literal suffix... (cached) ul
> checking for wchar_t integer literal suffix... (cached) u
> checking for wint_t integer literal suffix... (cached) u
> checking for strverscmp... no
> checking whether mkdir is declared... yes
> checking absolute name of <sys/stat.h>... ///usr/include/sys/stat.h
> checking for unistd.h... (cached) yes
> checking for vasnprintf... no
> checking for ptrdiff_t... (cached) yes
> checking for snprintf... (cached) yes
> checking for wcslen... yes
> checking for stdint.h... (cached) no
> checking if we have Windows sockets and WSAStartup/WSACleanup... no
> ***
> *** Detecting options for shared libraries...
>
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for non-GNU ld... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... no
> checking for /usr/bin/ld option to reload object files... -r
> checking for BSD-compatible nm... /usr/bin/nm -p
> checking how to recognise dependent libraries... file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> checking how to run the C++ preprocessor... aCC -E
> checking for g77... no
> checking for xlf... no
> checking for f77... no
> checking for frt... no
> checking for pgf77... no
> checking for cf77... no
> checking for fort77... no
> checking for fl32... no
> checking for af77... no
> checking for xlf90... no
> checking for f90... no
> checking for pgf90... no
> checking for pghpf... no
> checking for epcf90... no
> checking for gfortran... no
> checking for g95... no
> checking for xlf95... no
> checking for f95... no
> checking for fort... no
> checking for ifort... no
> checking for ifc... no
> checking for efc... no
> checking for pgf95... no
> checking for lf95... no
> checking for ftn... no
> checking whether we are using the GNU Fortran 77 compiler... no
> checking whether  accepts -g... no
> checking the maximum length of command line arguments... 262144
> checking command to parse /usr/bin/nm -p output from aCC -Ae object... ok
> checking for objdir... .libs
> checking for ar... ar
> checking for ranlib... (cached) ranlib
> checking for strip... strip
> checking for aCC -Ae option to produce PIC... 
> checking if aCC -Ae static flag -Wl,-a -Wl,archive works... yes
> checking if aCC -Ae supports -c -o file.o... yes
> checking whether the aCC -Ae linker (/usr/bin/ld) supports shared libraries... yes
> checking dynamic linker characteristics... hpux11.11 dld.sl
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... no
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> configure: creating libtool
> appending configuration tag "CXX" to libtool
> checking whether the aCC linker (/usr/bin/ld) supports shared libraries... yes
> checking for aCC option to produce PIC... 
> checking if aCC static flag -Wl,-a -Wl,archive works... yes
> checking if aCC supports -c -o file.o... yes
> checking whether the aCC linker (/usr/bin/ld) supports shared libraries... yes
> checking dynamic linker characteristics... hpux11.11 dld.sl
> checking how to hardcode library paths into programs... immediate
> appending configuration tag "F77" to libtool
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating po/Makefile.in
> config.status: WARNING:  po/Makefile.in.in seems to ignore the --datarootdir setting
> config.status: creating doc/Makefile
> config.status: creating doc/examples/Makefile
> config.status: creating doc/scripts/Makefile
> config.status: creating doc/manpages/Makefile
> config.status: creating doc/reference/Makefile
> config.status: creating gl/Makefile
> config.status: creating lgl/Makefile
> config.status: creating tests/Makefile
> config.status: creating tests/rsa-md5-collision/Makefile
> config.status: creating tests/pkcs1-padding/Makefile
> config.status: creating tests/pkcs8-decode/Makefile
> config.status: creating tests/pkcs12-decode/Makefile
> config.status: creating includes/Makefile
> config.status: creating includes/gnutls/gnutls.h
> config.status: creating lib/Makefile
> config.status: creating lib/minitasn1/Makefile
> config.status: creating lib/x509/Makefile
> config.status: creating libextra/Makefile
> config.status: creating libextra/openpgp/Makefile
> config.status: creating libextra/opencdk/Makefile
> config.status: creating libextra/minilzo/Makefile
> config.status: creating src/Makefile
> config.status: creating src/x509/Makefile
> config.status: creating src/srp/Makefile
> config.status: creating src/openpgp/Makefile
> config.status: creating src/cfg/Makefile
> config.status: creating src/cfg/platon/Makefile
> config.status: creating src/cfg/platon/str/Makefile
> config.status: creating lib/libgnutls-config
> config.status: creating libextra/libgnutls-extra-config
> config.status: creating lib/gnutls.pc
> config.status: creating libextra/gnutls-extra.pc
> config.status: creating config.h
> config.status: executing default-1 commands
> config.status: creating po/POTFILES
> config.status: creating po/Makefile
> config.status: executing depfiles commands
> config.status: executing chmod-config commands
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls




From simon at josefsson.org  Tue Mar 11 16:51:12 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Mar 2008 16:51:12 +0100
Subject: [Help-gnutls] Re: Unable to make gnutls in HPUX
In-Reply-To: <922d0b4d0802180406i12d8ca07ldf6240e984f97490@mail.gmail.com>
	(Haidar Habib's message of "Mon, 18 Feb 2008 17:36:14 +0530")
References: <922d0b4d0802150309h4d448b12u256daee7461f8f4e@mail.gmail.com>
	<87wsp2tsrl.fsf@mocca.josefsson.org>
	<922d0b4d0802180406i12d8ca07ldf6240e984f97490@mail.gmail.com>
Message-ID: <87r6ehjm33.fsf@mocca.josefsson.org>

"Haidar Habib" <h.habib at gmail.com> writes:

> Hi Simon,
>
> Actually my application is written in C++ so I think C++ library is needed.

Btw, are you sure you are using gnutlsxx.h in your C++ application?  It
is perfectly fine to only use the C library from C++ applications.  Just
because it is written in C++ doesn't mean it will need the GnuTLS C++
library.

/Simon




From simon at josefsson.org  Tue Mar 11 16:56:49 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 11 Mar 2008 16:56:49 +0100
Subject: [Help-gnutls] Re: compilation issues of gnutls-1.4.1 in HPUX
In-Reply-To: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	(Haidar Habib's message of "Mon, 18 Feb 2008 13:00:47 +0530")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
Message-ID: <87myp5jltq.fsf@mocca.josefsson.org>

"Haidar Habib" <h.habib at gmail.com> writes:

> Hi,
>
> Following errors occurred when I compiled gnutls-1.4.1. Befor this I
> successfully built libgcrypt-1.2.3 and libgcrypt-1.2.3.
> Pls give some suggestions in this regard.
>
> Error 359: "serv.c", line 646 # The expression on the left side of the
> '->' (arrow member access operator) must be a pointer to completed
> struct object type; the type of the left side is 'const
> sockaddr_storage *' and 'struct sockaddr_storage' has not been defined
> yet.
>       switch (addr->ss_family)
>               ^^^^
> Error 628: "serv.c", line 673 # "sockaddr_storage#5 client_address"
> ["serv.c", line 673] cannot be defined to have an incomplete type.
>       struct sockaddr_storage client_address;
>                               ^^^^^^^^^^^^^^
> Warning 942: "serv.c", line 916 # Types 'int *' and 'fd_set *' are not
> assignment-compatible.
>           n = select (n + 1, &rd, &wr, NULL, NULL);
>                              ^
> Warning 942: "serv.c", line 916 # Types 'int *' and 'fd_set *' are not
> assignment-compatible.
>           n = select (n + 1, &rd, &wr, NULL, NULL);
>                                   ^
> Error 244: "serv.c", line 932 # sizeof may not be applied to an
> undefined struct.
>               calen = sizeof (client_address);

It seems your platform doesn't implement sockaddr_storage properly.
According to:

http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/socket.h.html

socket.h shall declare the sockaddr_storage structure, and it shall
contain the ss_family member.

Maybe you could upgrade the HP-UX version?

It looks rather complicated to work around this problem, and may involve
not using getaddrinfo at all.  Someone familiar with getaddrinfo and
HP-UX needs to investigate this problem further.  It may be possible to
work around this problem by adding a gnulib module, but HP-UX knowledge
is needed.

/Simon




From mike at reys.be  Tue Mar 11 16:58:34 2008
From: mike at reys.be (mike at reys.be)
Date: Tue, 11 Mar 2008 16:58:34 +0100 (CET)
Subject: [Help-gnutls] Not at home
Message-ID: <20080311155834.29B1838932FF7@zulu.openminds.be>

Hi,

thanks for your mail, I'm travelling and reading my mail might be
difficult at times. I'll get back to you as soon as possible.

Cheers,

Mike





From dbreiser at gmail.com  Tue Mar 18 06:16:34 2008
From: dbreiser at gmail.com (David Reiser)
Date: Tue, 18 Mar 2008 01:16:34 -0400
Subject: [Help-gnutls] duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87myp5jltq.fsf@mocca.josefsson.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
Message-ID: <D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>

I'm trying to build gnutls 2.2.2 with fink installed dependencies on a  
ppc Mac running OS X 10.5.2.

If I use --disable-guile, the build seems to go fine. But if I leave  
out the --disable switch, the build fails with:

gcc -std=gnu99 -dynamiclib ${wl}-undefined ${wl}dynamic_lookup -o
.libs/libguile-gnutls-v-1.0.0.0.dylib
.libs/libguile_gnutls_v_1_la-core.o
.libs/libguile_gnutls_v_1_la-errors.o
.libs/libguile_gnutls_v_1_la-utils.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/asnprintf.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/dummy.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/gc-libgcrypt.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/gc-pbkdf2-sha1.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/md2.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/memmem.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/printf-args.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/printf-parse.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/read-file.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/strverscmp.o
.libs/libguile-gnutls-v-1.lax/liblgnu.a/vasnprintf.o
-L/sw/lib ../../lib/.libs/libgnutls.dylib
   /sw/lib/libtasn1.dylib
   /sw/lib/libgcrypt.dylib
   /sw/lib/libpth.dylib
   /sw/lib/libgpg-error.dylib
   /sw/lib/libintl.dylib
   /sw/lib/libiconv.dylib
-lc /sw/lib/libguile.dylib
     /sw/lib/libgmp.dylib
-lm /sw/lib/libltdl.dylib
-install_name  /sw/lib/libguile-gnutls-v-1.0.dylib
-compatibility_version 1
-current_version 1.0
-Wl,-single_module


ld: duplicate symbol ___gmpz_abs in
.libs/libguile_gnutls_v_1_la-errors.o and
.libs/libguile_gnutls_v_1_la-core.o


and grepping in the source tree suggests the same symbol is defined in  
yet a third file:

$ grep -R ___gmpz_abs .
Binary file ./guile/src/.libs/libguile_gnutls_v_1_la-core.o matches
Binary file ./guile/src/.libs/libguile_gnutls_v_1_la-errors.o matches
Binary file ./guile/src/.libs/libguile_gnutls_v_1_la-utils.o matches
Binary file ./guile/src/libguile_gnutls_v_1_la-core.o matches
Binary file ./guile/src/libguile_gnutls_v_1_la-errors.o matches
Binary file ./guile/src/libguile_gnutls_v_1_la-utils.o matches

Apple's linker isn't known for being particularly bug free, but does  
anyone have any suggestions as to how I can fix this?

Dave
--
David Reiser
dbreiser at gmail.com







From ludo at gnu.org  Tue Mar 18 10:32:55 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 18 Mar 2008 10:32:55 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
Message-ID: <87myowwf5k.fsf@gnu.org>

Hi,

David Reiser <dbreiser at gmail.com> writes:

> ld: duplicate symbol ___gmpz_abs in
> .libs/libguile_gnutls_v_1_la-errors.o and
> .libs/libguile_gnutls_v_1_la-core.o

That's weird since `__gmpz_abs' is supposedly inline.

Can you try compiling something like:

  #include <gmp.h>

  void
  foo (mpz_t a, mpz_t b)
  {
    mpz_abs (a, b);
  }

And then run:

  $ nm -g the-file.o | grep mpz_abs

Thanks,
Ludovic.





From dbreiser at gmail.com  Tue Mar 18 17:05:34 2008
From: dbreiser at gmail.com (David Reiser)
Date: Tue, 18 Mar 2008 12:05:34 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87myowwf5k.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
Message-ID: <8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>


On Mar 18, 2008, at 5:32 AM, Ludovic Court?s wrote:

> Hi,
>
> David Reiser <dbreiser at gmail.com> writes:
>
>> ld: duplicate symbol ___gmpz_abs in
>> .libs/libguile_gnutls_v_1_la-errors.o and
>> .libs/libguile_gnutls_v_1_la-core.o
>
> That's weird since `__gmpz_abs' is supposedly inline.
>
> Can you try compiling something like:
>
>  #include <gmp.h>
>
>  void
>  foo (mpz_t a, mpz_t b)
>  {
>    mpz_abs (a, b);
>  }
>
> And then run:
>
>  $ nm -g the-file.o | grep mpz_abs
>
> Thanks,
> Ludovic.


It turns out I am incapable of accomplishing that. Sorry. I can muddle  
through patches and packaging, but seem unable to resolve simple C  
problems. Using your fragment, I get:

Undefined symbols:
   "_main", referenced from:
       start in crt1.10.5.o
   "___gmpz_abs", referenced from:
       _foo in ccfgyRYz.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

If I throw in a 'main ()' to quiet the first error, I end up with  
'error: syntax error before ?{? token'

That said, there have been other problems with inline functions and  
Apple's linker in OS X 10.5.2. I'll try building on 10.4 to see if  
that works.

Thanks for the help.

Dave
--
David Reiser
dbreiser at gmail.com







From ludo at gnu.org  Tue Mar 18 21:01:29 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 18 Mar 2008 21:01:29 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
Message-ID: <87ve3jn6na.fsf@gnu.org>

Hi,

David Reiser <dbreiser at gmail.com> writes:

> On Mar 18, 2008, at 5:32 AM, Ludovic Court?s wrote:

>> Can you try compiling something like:
>>
>>  #include <gmp.h>
>>
>>  void
>>  foo (mpz_t a, mpz_t b)
>>  {
>>    mpz_abs (a, b);
>>  }
>>
>> And then run:
>>
>>  $ nm -g the-file.o | grep mpz_abs

> It turns out I am incapable of accomplishing that.

Actually you just want to compile the file, not to link it and create an
executable.

So, assuming you copied the above code fragment in `the-file.c', then
you just need to compile it with:

  $ gcc -c the-file.c

After which you can run `nm' as noted above.

Thanks,
Ludovic.





From dbreiser at gmail.com  Wed Mar 19 02:59:17 2008
From: dbreiser at gmail.com (David Reiser)
Date: Tue, 18 Mar 2008 21:59:17 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87ve3jn6na.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
Message-ID: <01646597-495C-4D75-8F65-665209687F06@gmail.com>


On Mar 18, 2008, at 4:01 PM, Ludovic Court?s wrote:

> Hi,
>
> David Reiser <dbreiser at gmail.com> writes:
>
>> On Mar 18, 2008, at 5:32 AM, Ludovic Court?s wrote:
>
>>> Can you try compiling something like:
>>>
>>> #include <gmp.h>
>>>
>>> void
>>> foo (mpz_t a, mpz_t b)
>>> {
>>>   mpz_abs (a, b);
>>> }
>>>
>>> And then run:
>>>
>>> $ nm -g the-file.o | grep mpz_abs
>
>> It turns out I am incapable of accomplishing that.
>
> Actually you just want to compile the file, not to link it and  
> create an
> executable.
>
> So, assuming you copied the above code fragment in `the-file.c', then
> you just need to compile it with:
>
>  $ gcc -c the-file.c
>
> After which you can run `nm' as noted above.
>
> Thanks,
> Ludovic.
>
It has been so long since I wanted to prevent a linker from doing its  
thing, I forgot it was easy.

$ nm -g bar.o | grep mpz_abs
          U ___gmpz_abs

Thanks for your help and patience.

Dave
--
David Reiser
dbreiser at gmail.com







From ludo at gnu.org  Wed Mar 19 13:03:19 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 19 Mar 2008 13:03:19 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
Message-ID: <87d4pqj4zc.fsf@gnu.org>

Hi,

David Reiser <dbreiser at gmail.com> writes:

> $ nm -g bar.o | grep mpz_abs
>          U ___gmpz_abs

Hmm, can you do the same on the offending files, i.e.,

  $ for i in errors core; do
    nm -g ./guile/src/.libs/libguile_gnutls_v_1_la-$i.o | grep mpz_abs
    done

Thanks,
Ludovic.





From dbreiser at gmail.com  Wed Mar 19 14:32:48 2008
From: dbreiser at gmail.com (David Reiser)
Date: Wed, 19 Mar 2008 09:32:48 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87d4pqj4zc.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
Message-ID: <FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>


On Mar 19, 2008, at 8:03 AM, Ludovic Court?s wrote:

> Hi,
>
> David Reiser <dbreiser at gmail.com> writes:
>
>> $ nm -g bar.o | grep mpz_abs
>>         U ___gmpz_abs
>
> Hmm, can you do the same on the offending files, i.e.,
>
>  $ for i in errors core; do
>    nm -g ./guile/src/.libs/libguile_gnutls_v_1_la-$i.o | grep mpz_abs
>    done
>
> Thanks,
> Ludovic.

00000000 T ___gmpz_abs
00000000 T ___gmpz_abs

and if I add utils to the list, it's there the same way, so I don't  
know why the linker isn't complaining about that also.

The 10.5 linker does have problems (or at least differences involving)  
inline functions. For glib 2.16.1, we have to force
#  define G_INLINE_FUNC static inline
to get some things depending on glib to compile.

Thanks.
--
David Reiser
dbreiser at gmail.com







From simon at josefsson.org  Wed Mar 19 16:01:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Mar 2008 16:01:43 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com> (David Reiser's
	message of "Wed, 19 Mar 2008 09:32:48 -0400")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
Message-ID: <87od9adag8.fsf@mocca.josefsson.org>

David Reiser <dbreiser at gmail.com> writes:

> On Mar 19, 2008, at 8:03 AM, Ludovic Court?s wrote:
>
>> Hi,
>>
>> David Reiser <dbreiser at gmail.com> writes:
>>
>>> $ nm -g bar.o | grep mpz_abs
>>>         U ___gmpz_abs
>>
>> Hmm, can you do the same on the offending files, i.e.,
>>
>>  $ for i in errors core; do
>>    nm -g ./guile/src/.libs/libguile_gnutls_v_1_la-$i.o | grep mpz_abs
>>    done
>>
>> Thanks,
>> Ludovic.
>
> 00000000 T ___gmpz_abs
> 00000000 T ___gmpz_abs
>
> and if I add utils to the list, it's there the same way, so I don't
> know why the linker isn't complaining about that also.
>
> The 10.5 linker does have problems (or at least differences involving)
> inline functions. For glib 2.16.1, we have to force
> #  define G_INLINE_FUNC static inline
> to get some things depending on glib to compile.

I have some vague memory about reading that the semantics of 'inline'
has changed recently.  If you don't mark inline functions static, they
will be exported as well, because they may be needed in other files.
That would explain this problem.  I may be remembering incorrectly, but
it may be that this new behaviour is actually correct.

I can't find this symbol in the GnuTLS sources, so I would suspect it is
used in Guile?

This reminds me, there is a bunch of warnings about use of inline
functions in the gnutls-guile code, such as:

core.c:1335: warning: function ?set_certificate_file? can never be inlined because it uses alloca (override using the always_inline attribute)
core.c:1335: warning: inlining failed in call to ?set_certificate_file?: function not inlinable

I don't think this is related, though.

/Simon




From smurf at smurf.noris.de  Wed Mar 19 16:27:00 2008
From: smurf at smurf.noris.de (Matthias Urlichs)
Date: Wed, 19 Mar 2008 16:27:00 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87od9adag8.fsf@mocca.josefsson.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org>
Message-ID: <20080319152700.GF21554@kiste.smurf.noris.de>

Hi,

Simon Josefsson:
> I have some vague memory about reading that the semantics of 'inline'
> has changed recently.

s/recently/some years ago/. And probably s/semantics/optimization strategy/,
which is somewhat more fluid (and therefore more likely to trigger bugs
anywhere _but_ in your own environment :-P ).

To summarize: If you want to force inlining, gcc requires the
"always_inline" attribute.

In general, s/inline/static &/ makes sense.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf at smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
By MEER biz doo SCHOIN...
		-- Zippy the Pinhead




From simon at josefsson.org  Wed Mar 19 16:38:39 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 19 Mar 2008 16:38:39 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <20080319152700.GF21554@kiste.smurf.noris.de> (Matthias Urlichs's
	message of "Wed, 19 Mar 2008 16:27:00 +0100")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org>
	<20080319152700.GF21554@kiste.smurf.noris.de>
Message-ID: <87k5jy7mgw.fsf@mocca.josefsson.org>

Matthias Urlichs <smurf at smurf.noris.de> writes:

> Hi,
>
> Simon Josefsson:
>> I have some vague memory about reading that the semantics of 'inline'
>> has changed recently.
>
> s/recently/some years ago/. And probably s/semantics/optimization strategy/,
> which is somewhat more fluid (and therefore more likely to trigger bugs
> anywhere _but_ in your own environment :-P ).
>
> To summarize: If you want to force inlining, gcc requires the
> "always_inline" attribute.
>
> In general, s/inline/static &/ makes sense.

Thanks for clarifying.

For this problem, perhaps the problem is old gmp.h header that doesn't
use inline properly?  Anyway, I'm not sure it is a gnutls problem, we
don't use gmp.h and don't use the symbol in the error message.

/Simon




From ludo at gnu.org  Wed Mar 19 16:55:16 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 19 Mar 2008 16:55:16 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org>
Message-ID: <87k5jy4skb.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> I have some vague memory about reading that the semantics of 'inline'
> has changed recently.  If you don't mark inline functions static, they
> will be exported as well, because they may be needed in other files.
> That would explain this problem.  I may be remembering incorrectly, but
> it may be that this new behaviour is actually correct.

GMP must be using "extern inline", whose C99 semantics may be different
from the original GCC semantics (though I don't recall the details).

Anyway, I see that GnuTLS is now compiled with `-std=c99', which may be
the reason for the semantic change.  In particular, for libguile, I see
a number of inline-related warnings, which did not show up earlier:

  .../libguile/inline.h:80: warning: C99 inline functions are not supported; using GNU89

This would suggest that GCC was able to automagically detect that
libguile isn't C99-aware, which it failed to do for GMP.

> I can't find this symbol in the GnuTLS sources, so I would suspect it is
> used in Guile?

It's from GMP, the GNU Multiple Precision arithmetic library
(http://gmplib.org), a dependency of Guile.

This should probably be reported as a GMP issue.  GMP should add some
C99 feature tests to adjust its use of "inline"---the easiest solution
being to use the `gnu_inline' attribute, but that won't fix things for
non-GCC C99 compilers.  Same for Guile.

> This reminds me, there is a bunch of warnings about use of inline
> functions in the gnutls-guile code, such as:
>
> core.c:1335: warning: function ?set_certificate_file? can never be inlined because it uses alloca (override using the always_inline attribute)
> core.c:1335: warning: inlining failed in call to ?set_certificate_file?: function not inlinable

That's a mistake on my side: it shouldn't be inline since it uses
`alloca ()'.

I just pushed the two attached patches to `master' (I'll let you apply
them to whatever other branch may need it :-)).  The first one addresses
your warning, while the second one add `-fgnu89-inline' which should fix
both the warnings I'm seeing here (shown above) and David's compilation
problem.

David: can you confirm?  (You don't even have to apply the patch, you
can just try compiling the `guile' directory with
"make CFLAGS=-fgnu89-inline" I think.)

Thanks,
Ludovic.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-guile-Don-t-declare-inline-functions-that-use-al.patch
Type: text/x-patch
Size: 1536 bytes
Desc: The first patch
URL: </pipermail/attachments/20080319/7875dd53/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-guile-Compile-with-fgnu89-inline.patch
Type: text/x-patch
Size: 956 bytes
Desc: The second one
URL: </pipermail/attachments/20080319/7875dd53/attachment-0001.bin>

From dbreiser at gmail.com  Thu Mar 20 02:50:19 2008
From: dbreiser at gmail.com (David Reiser)
Date: Wed, 19 Mar 2008 21:50:19 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87k5jy4skb.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
Message-ID: <24445E26-11FC-479E-8501-8E4516194F52@gmail.com>


On Mar 19, 2008, at 11:55 AM, Ludovic Court?s wrote:

> [...]
>
> David: can you confirm?  (You don't even have to apply the patch, you
> can just try compiling the `guile' directory with
> "make CFLAGS=-fgnu89-inline" I think.)
>
> Thanks,
> Ludovic.
> [...]

I get either the  same duplicate symbols error (but I'm not sure that  
wasn't a case where I already had the object files from the previous  
build and the system figured it would skip right to linking), and if I  
do a make distclean and try to rebuild everything, I get:

cc1: error: unrecognized command line option "-fgnu89-inline"

I also can't try the patch as written because the gettext I have isn't  
recent enough to successfully run autoreconf on the gnutls sources.

I agree that fink should take this up with gmp, as we'll undoubtedly  
run into the issue many more times.

Meanwhile, gnutls 2.2.2 builds fine without the guile bindings, and so  
far I have no complaints even though the current version has been  
added to several dependency trees. I'm even thinking I should make the  
guile bindings optional anyway.

Thanks for all the help.

Dave
--
David Reiser
dbreiser at gmail.com







From ludo at gnu.org  Thu Mar 20 09:30:16 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 20 Mar 2008 09:30:16 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
Message-ID: <87ve3h4x2f.fsf@gnu.org>

Hello,

David Reiser <dbreiser at gmail.com> writes:

> cc1: error: unrecognized command line option "-fgnu89-inline"

Damn it, I just noticed that this option appeared in GCC 4.1.3 [0].  The
attached patch (applied to `master') fixes it (Simon: can you apply it
to other branches as well, if needed?).

What version of GCC are you using?  Can you list all the compilation
options that are actually used when compiling things under `guile/src'?

BTW, is there any reason why GnuTLS is now compiled in C99 mode?  It
doesn't seem to be explicitly set in `configure.in', so maybe some
Gnulib module requires it somehow?

Thanks for your help,
Ludovic.

[0] http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00793.html
    The documentation also states that the actual "inline" semantic
    change occurs starting with GCC 4.3.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Check-whether-fgnu89-inline-is-supported-before-u.patch
Type: text/x-patch
Size: 3016 bytes
Desc: The patch
URL: </pipermail/attachments/20080320/d9375a05/attachment.bin>

From simon at josefsson.org  Thu Mar 20 10:47:31 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Mar 2008 10:47:31 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87ve3h4x2f.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 20
	Mar 2008 09:30:16 +0100")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org>
Message-ID: <87r6e5bubw.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hello,
>
> David Reiser <dbreiser at gmail.com> writes:
>
>> cc1: error: unrecognized command line option "-fgnu89-inline"
>
> Damn it, I just noticed that this option appeared in GCC 4.1.3 [0].  The
> attached patch (applied to `master') fixes it (Simon: can you apply it
> to other branches as well, if needed?).

Thanks.  I haven't branched off gnutls_2_4_x yet, fortunately, so there
is nothing for me to do about this.

> BTW, is there any reason why GnuTLS is now compiled in C99 mode?  It
> doesn't seem to be explicitly set in `configure.in', so maybe some
> Gnulib module requires it somehow?

Yeah, gnulib calls AC_PROG_CC_STDC, which in modern autoconf enables C99
mode if the compiler supports it.  The test looks like:

checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99

Anyway, I don't see any harm in setting the compiler in C99 mode if the
compiler supports it.  GnuTLS optionally use several C99 features, such
as __func__, CPP macros with flexible number of parameters, stdbool.h.
If the compiler doesn't supports those, we'll disable those features or
use our gnulib-workarounds, which seems sub-optimal.  We want our code
to work with C99.

I still don't see how this problem occur though.  Exactly how is the
gmpz_abs symbol pulled into guile/src/*.o files?  If gmpz_abs is inline
in gmp.h, should that be inlined into the guile code?  Does setting the
compiler in gnu99 mode also set the linker in a different mode, that
causes this problem?

David, could you try build GnuTLS and passing ./configure the parameter
'ac_cv_prog_cc_c99=no'?  Make sure configure output looks like:

checking for gcc option to accept ISO C99... (cached) unsupported

/Simon




From ludo at gnu.org  Thu Mar 20 13:41:44 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 20 Mar 2008 13:41:44 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
Message-ID: <87prtpsh2v.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> writes:

> Anyway, I don't see any harm in setting the compiler in C99 mode if the
> compiler supports it.

One possible problem is that you end up writing C99 code, using
C99-specific things like, say, C++-style comments, declarations not at
the beginning of a block, etc.  These things will break with non-C99
compilers.

> GnuTLS optionally use several C99 features, such
> as __func__, CPP macros with flexible number of parameters, stdbool.h.

C99 headers can usually be used even without a C99 compiler (well,
provided they're available, of course).

> If the compiler doesn't supports those, we'll disable those features or
> use our gnulib-workarounds, which seems sub-optimal.  We want our code
> to work with C99.

To "work with C99" or to "require C99"?  Surely either is acceptable,
but I have the impression that there's a slow movement towards the
latter.

> I still don't see how this problem occur though.  Exactly how is the
> gmpz_abs symbol pulled into guile/src/*.o files?  If gmpz_abs is inline
> in gmp.h, should that be inlined into the guile code?  Does setting the
> compiler in gnu99 mode also set the linker in a different mode, that
> causes this problem?

<libguile.h> includes <libguile/numbers.h>, which in turn includes
<gmp.h>, which contains declarations and "extern inline" definitions (in
the "GNU89" sense).

Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o'
objects produced on MacOS X, I have now idea.  On GNU/Linux with GCC
4.2.3, it never happens, whether compiled with `-std=c99' or not.

Help is welcome.  :-)

Thanks,
Ludovic.





From simon at josefsson.org  Thu Mar 20 15:32:05 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Mar 2008 15:32:05 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87prtpsh2v.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 20
	Mar 2008 13:41:44 +0100")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org>
Message-ID: <87y78dv53u.fsf@mocca.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> writes:
>
>> Anyway, I don't see any harm in setting the compiler in C99 mode if the
>> compiler supports it.
>
> One possible problem is that you end up writing C99 code, using
> C99-specific things like, say, C++-style comments, declarations not at
> the beginning of a block, etc.  These things will break with non-C99
> compilers.

Yes, but anything like that would be bugs.  We still target C89 + POSIX
sockets.  Gcc's default mode is gnu89 (I think?), which does permit some
things from C99, so we have had this problem forever.

I used to build gnutls on solaris, aix, hpux etc for every release using
their native compilers, but I don't have the resources to do it any
more.  If someone have access to these platforms and want to setup an
autobuilder, we would catch any regression soon (btw, see
<http://autobuild.josefsson.org/>).

>> If the compiler doesn't supports those, we'll disable those features or
>> use our gnulib-workarounds, which seems sub-optimal.  We want our code
>> to work with C99.
>
> To "work with C99" or to "require C99"?  Surely either is acceptable,
> but I have the impression that there's a slow movement towards the
> latter.

Unfortunately, I think it is too early to require C99.  A lot of
embedded and less capable systems need gnutls, and they barely have C89
support even these days.

>> I still don't see how this problem occur though.  Exactly how is the
>> gmpz_abs symbol pulled into guile/src/*.o files?  If gmpz_abs is inline
>> in gmp.h, should that be inlined into the guile code?  Does setting the
>> compiler in gnu99 mode also set the linker in a different mode, that
>> causes this problem?
>
> <libguile.h> includes <libguile/numbers.h>, which in turn includes
> <gmp.h>, which contains declarations and "extern inline" definitions (in
> the "GNU89" sense).

Ah, that helps.

> Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o'
> objects produced on MacOS X, I have now idea.

As far as I can tell, it would only happen if some code in gnutls uses
some guile declaration that implicitly calls gmpz_abs.  However, I
couldn't find any: the only libguile header that mention gmp types or
functions is numbers.h:

jas at mocca:~$ grep -i mpz /usr/include/libguile/*
/usr/include/libguile/numbers.h:/* Each bignum is just an mpz_t stored in a double cell starting at word 1. */
/usr/include/libguile/numbers.h:#define SCM_I_BIG_MPZ(x) (*((mpz_t *) (SCM_CELL_OBJECT_LOC((x),1))))
/usr/include/libguile/numbers.h:SCM_API void scm_to_mpz (SCM x, mpz_t rop);
/usr/include/libguile/numbers.h:SCM_API SCM  scm_from_mpz (mpz_t rop);
jas at mocca:~$ 

I don't see how mpz_abs is called here though.

> On GNU/Linux with GCC 4.2.3, it never happens, whether compiled with
> `-std=c99' or not.

'extern inline' means, I think, that stand-alone object code is still
generated and can be used by external code.  So any code that use calls
mpz_abs would declare an external symbol as well.  However, it seems to
me that this should only be a weak symbol, so I don't understand how
there could be a symbol collision.

Hm.  There is actually some interesting discussion in gmp.h:

/* The following are provided as inlines where possible, but always exist as
   library functions too, for binary compatibility.

   Within gmp itself this inlining generally isn't relied on, since it
   doesn't get done for all compilers, whereas if something is worth
   inlining then it's worth arranging always.

   There are two styles of inlining here.  When the same bit of code is
   wanted for the inline as for the library version, then __GMP_FORCE_foo
   arranges for that code to be emitted and the __GMP_EXTERN_INLINE
   directive suppressed, eg. mpz_fits_uint_p.  When a different bit of code
   is wanted for the inline than for the library version, then
   __GMP_FORCE_foo arranges the inline to be suppressed, eg. mpz_abs.  */

#if defined (__GMP_EXTERN_INLINE) && ! defined (__GMP_FORCE_mpz_abs)
__GMP_EXTERN_INLINE void
mpz_abs (mpz_ptr __gmp_w, mpz_srcptr __gmp_u)
{
  if (__gmp_w != __gmp_u)
    mpz_set (__gmp_w, __gmp_u);
  __gmp_w->_mp_size = __GMP_ABS (__gmp_w->_mp_size);
}
#endif

/Simon




From simon at josefsson.org  Thu Mar 20 15:33:38 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 20 Mar 2008 15:33:38 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87prtpsh2v.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?=
	=?iso-8859-1?Q?=22's?= message of "Thu, 20
	Mar 2008 13:41:44 +0100")
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org>
Message-ID: <87tzj1v519.fsf@mocca.josefsson.org>

David, which GMP version is installed on this system?

/Simon




From dbreiser at gmail.com  Thu Mar 20 16:06:00 2008
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 20 Mar 2008 11:06:00 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87tzj1v519.fsf@mocca.josefsson.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87tzj1v519.fsf@mocca.josefsson.org>
Message-ID: <DBB0FC8A-D459-462F-84EB-081B8770955A@gmail.com>


On Mar 20, 2008, at 10:33 AM, Simon Josefsson wrote:

> David, which GMP version is installed on this system?
>
> /Simon


4.2.1 I have 4.2.2 available, but haven't upgraded yet. I can do that  
relatively easily if you think it will help.

A duplicate symbols linker error also arose in glib (2.14 and 2.16)  
for inline functions when Mac os x went from 10.4 to 10.5. Apple's  
linker isn't the most robust beast on the planet. The immediate fix  
for glib is to force G_INLINE_FUNC to be static inline.

Fink hasn't upgraded gnutls in quite a while (the last version was  
1.4.5), so I certainly haven't been up-to-date with gnutls progress.

I won't be able to get to the other suggestions until tonight. Thanks  
for the help.

Dave
--
David Reiser
dbreiser at gmail.com







From dbreiser at gmail.com  Fri Mar 21 03:24:54 2008
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 20 Mar 2008 22:24:54 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87ve3h4x2f.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org>
Message-ID: <A4759AB6-451A-423A-AD27-340FD7897235@gmail.com>


On Mar 20, 2008, at 4:30 AM, Ludovic Court?s wrote:
>
> What version of GCC are you using?  Can you list all the compilation
> options that are actually used when compiling things under `guile/ 
> src'?

Apple's gcc is 4.0.1.

is
  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../includes -I../../ 
includes -I../.. -I. -I/sw/include -g -O2 -D_REENTRANT -D_THREAD_SAFE - 
I/sw/include -I/sw/include -Wno-strict-prototypes -I../../lgl -I../../ 
lgl -I/sw/include -D_THREAD_SAFE -g -O2 -D_REENTRANT -D_THREAD_SAFE - 
Wno-pointer-sign -c core.c  -fno-common -DPIC -o .libs/ 
libguile_gnutls_v_1_la-core.o

enough info?

Dave
--
David Reiser
dbreiser at gmail.com







From dbreiser at gmail.com  Fri Mar 21 03:36:46 2008
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 20 Mar 2008 22:36:46 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87prtpsh2v.fsf@gnu.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org>
Message-ID: <05A920B9-2A8D-4228-9F50-C65A25AD8F78@gmail.com>


On Mar 20, 2008, at 8:41 AM, Ludovic Court?s wrote:

> Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o'
> objects produced on MacOS X, I have now idea.  On GNU/Linux with GCC
> 4.2.3, it never happens, whether compiled with `-std=c99' or not.


Don't be too quick to rule out an absurd bug in Apple's linker.

Dave
--
David Reiser
dbreiser at gmail.com







From dbreiser at gmail.com  Fri Mar 21 03:52:19 2008
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 20 Mar 2008 22:52:19 -0400
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
In-Reply-To: <87r6e5bubw.fsf@mocca.josefsson.org>
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
Message-ID: <059B5492-B671-4083-AFD3-55BEA46B0ED0@gmail.com>


On Mar 20, 2008, at 5:47 AM, Simon Josefsson wrote:

> I still don't see how this problem occur though.  Exactly how is the
> gmpz_abs symbol pulled into guile/src/*.o files?  If gmpz_abs is  
> inline
> in gmp.h, should that be inlined into the guile code?  Does setting  
> the
> compiler in gnu99 mode also set the linker in a different mode, that
> causes this problem?
>
> David, could you try build GnuTLS and passing ./configure the  
> parameter
> 'ac_cv_prog_cc_c99=no'?  Make sure configure output looks like:
>
> checking for gcc option to accept ISO C99... (cached) unsupported


Neither
ac_cv_proc_cc_c99=no ./configure ...
or
./configure [...] ac_cv_proc_cc_c99=no

prevented

checking for gcc option to accept ISO C99... -std=gnu99
checking for gcc -std=gnu99 option to accept ISO Standard C...  
(cached) -std=gnu99

Dave
--
David Reiser
dbreiser at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20080320/e213ce5f/attachment.htm>

From ludo at gnu.org  Thu Mar 27 15:00:42 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 27 Mar 2008 15:00:42 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
Message-ID: <873aqce06t.fsf@gnu.org>

Hi,

Sorry for taking so long.  I've browsed various mailing list archives
about the `G_INLINE_FUNC' problem (which is similar), but didn't find
any satisfactory explanation.  The workaround that's been applied boils
down to an `#ifdef __APPLE__' that avoids "extern inline" when on
Mac OS X.

The glib bug is http://bugzilla.gnome.org/show_bug.cgi?id=492152 .
The patch:
http://trac.macports.org/projects/macports/attachment/ticket/13006/glib2-inline.patch .

So, let's try to get a better understanding of what's going on...

David Reiser <dbreiser at gmail.com> writes:

> On Mar 18, 2008, at 4:01 PM, Ludovic Court?s wrote:
>> David Reiser <dbreiser at gmail.com> writes:
>>> On Mar 18, 2008, at 5:32 AM, Ludovic Court?s wrote:
>>>> Can you try compiling something like:
>>>>
>>>> #include <gmp.h>
>>>>
>>>> void
>>>> foo (mpz_t a, mpz_t b)
>>>> {
>>>>   mpz_abs (a, b);
>>>> }
>>>>
>>>> And then run:
>>>>
>>>> $ nm -g the-file.o | grep mpz_abs

>> So, assuming you copied the above code fragment in `the-file.c', then
>> you just need to compile it with:
>>
>>  $ gcc -c the-file.c

> $ nm -g bar.o | grep mpz_abs
>          U ___gmpz_abs

Can you try the same, but compiling with "gcc -O2" this time?  This
should force function inlining.

Thanks,
Ludovic.





From ludo at gnu.org  Thu Mar 27 15:04:01 2008
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 27 Mar 2008 15:04:01 +0100
Subject: [Help-gnutls] Re: duplicate symbols complaint on Mac OS X 10.5.2
References: <922d0b4d0802172330r33f794edu8b968adfee626357@mail.gmail.com>
	<87myp5jltq.fsf@mocca.josefsson.org>
	<D311DE37-F970-43EF-A1AB-394C6E407C16@gmail.com>
	<87myowwf5k.fsf@gnu.org>
	<8FD0D2D5-29C7-4E1B-9FB9-1CCB29E20438@gmail.com>
	<87ve3jn6na.fsf@gnu.org>
	<01646597-495C-4D75-8F65-665209687F06@gmail.com>
	<87d4pqj4zc.fsf@gnu.org>
	<FEB5CC46-BC82-44A6-BB6B-BE7EE1072B71@gmail.com>
	<87od9adag8.fsf@mocca.josefsson.org> <87k5jy4skb.fsf@gnu.org>
	<24445E26-11FC-479E-8501-8E4516194F52@gmail.com>
	<87ve3h4x2f.fsf@gnu.org> <87r6e5bubw.fsf@mocca.josefsson.org>
	<87prtpsh2v.fsf@gnu.org> <87y78dv53u.fsf@mocca.josefsson.org>
Message-ID: <87od90clgu.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> ludo at gnu.org (Ludovic Court?s) writes:

>> One possible problem is that you end up writing C99 code, using
>> C99-specific things like, say, C++-style comments, declarations not at
>> the beginning of a block, etc.  These things will break with non-C99
>> compilers.
>
> Yes, but anything like that would be bugs.  We still target C89 + POSIX
> sockets.  Gcc's default mode is gnu89 (I think?), which does permit some
> things from C99, so we have had this problem forever.

Compiling with `-std=c99' makes it harder to catch these "bugs".

> Unfortunately, I think it is too early to require C99.  A lot of
> embedded and less capable systems need gnutls, and they barely have C89
> support even these days.

Agreed.

>> Why it `__gmpz_abs' ends up as a global, exported symbol in the `.o'
>> objects produced on MacOS X, I have now idea.
>
> As far as I can tell, it would only happen if some code in gnutls uses
> some guile declaration that implicitly calls gmpz_abs.

Reports I've seen about the `G_INLINE_FUNC' issue in Glib (which is a
similar problem) seem to imply that something's wrong with Apple's
linker that prevents "extern inline" from working properly.

> 'extern inline' means, I think, that stand-alone object code is still
> generated and can be used by external code.  So any code that use calls
> mpz_abs would declare an external symbol as well.  However, it seems to
> me that this should only be a weak symbol, so I don't understand how
> there could be a symbol collision.

Indeed.

> Hm.  There is actually some interesting discussion in gmp.h:
>
> /* The following are provided as inlines where possible, but always exist as
>    library functions too, for binary compatibility.
>
>    Within gmp itself this inlining generally isn't relied on, since it
>    doesn't get done for all compilers, whereas if something is worth
>    inlining then it's worth arranging always.
>
>    There are two styles of inlining here.  When the same bit of code is
>    wanted for the inline as for the library version, then __GMP_FORCE_foo
>    arranges for that code to be emitted and the __GMP_EXTERN_INLINE
>    directive suppressed, eg. mpz_fits_uint_p.  When a different bit of code
>    is wanted for the inline than for the library version, then
>    __GMP_FORCE_foo arranges the inline to be suppressed, eg. mpz_abs.  */

Another possible investigation area...

Thanks,
Ludovic.