Mailing List Archive

On Monday 19 April 2004 15:44, Michael Nottebrock wrote:

> 3.) The replacement function for putc_unlocked.c does not compile:
>
> cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall
> -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' ||
> echo './'`putc_unlocked.c
> putc_unlocked.c:29: redefinition of `__sputc'
> /usr/include/stdio.h:361: `__sputc' previously defined here

I just remembered how I worked around that in the newpg port, autoconf's check
for putc_unlocked is buggy and wrongly detects putc_unlocked as missing in
FreeBSD... guess there's nothing you can do about that. ;-)

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

At Mon, 19 Apr 2004 15:44:51 +0200,
Michael Nottebrock wrote:
>
> 2.) assuan-domain-connect.c also needs sys/types.h included as described above
> and additionally needs to include isc/eventlib.h for the iovec structure.

The standard header for iovec is <sys/uio.h>. Is that avaiable and
defines struct iovec on your system?

> 3.) The replacement function for putc_unlocked.c does not compile:
>
> cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall
> -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' ||
> echo './'`putc_unlocked.c
> putc_unlocked.c:29: redefinition of `__sputc'
> /usr/include/stdio.h:361: `__sputc' previously defined here

This seems spurious. Maybe putc_unlocked is only defined as a macro
on BSD, and thus circumvents the autoconf tests? This would sound
broken to me (it may be allowed to define it as a macro, but it should
still be defined as a function in the library).

Thanks,
Marcus

On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said:

> 1.) assuan-socket-connect.c and assuan-socket-server.c need an additional
> #include <sys/types.h> before #include <sys/socket.h> (this bug exists in the
Thanks.

> 2.) assuan-domain-connect.c also needs sys/types.h included as described above
> and additionally needs to include isc/eventlib.h for the iovec structure.

We need to to write a autoconf check for them. You may for now simply
remove the function; it is currently not used.

> 3.) The replacement function for putc_unlocked.c does not compile:

> cc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -O -pipe -Wall
> -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'putc_unlocked.c' ||
> echo './'`putc_unlocked.c
> putc_unlocked.c:29: redefinition of `__sputc'
> /usr/include/stdio.h:361: `__sputc' previously defined here

Seems that the configure check for putc_unlocked failed; can you
please check this?

Werner

On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said:

> #include <sys/types.h> before #include <sys/socket.h> (this bug exists in the
> local copies of libassuan in pinentry/dirmngr as well).

pinentry uses a struipped down version of libassuan and dirmngr does
not anymore source include libassuan. May it be that your versions
are too old?

Werner

On Monday 19 April 2004 16:46, Werner Koch wrote:
> On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said:
> > #include <sys/types.h> before #include <sys/socket.h> (this bug exists in
> > the local copies of libassuan in pinentry/dirmngr as well).
>
> pinentry uses a struipped down version of libassuan and dirmngr does
> not anymore source include libassuan. May it be that your versions
> are too old?

They're behind the latest releases indeed - I'm not sure why I didn't update
them, perhaps there was trouble. I'll updating the whole bunch to the latest
versions later and report any troubles I'm running into.

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

On Monday 19 April 2004 16:34, Marcus Brinkmann wrote:

> This seems spurious. Maybe putc_unlocked is only defined as a macro
> on BSD, and thus circumvents the autoconf tests? This would sound
> broken to me (it may be allowed to define it as a macro, but it should
> still be defined as a function in the library).

Yes, it's a macro. However, I don't see what's wrong about that other than
making autoconf's life harder.

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

On Mon, 19 Apr 2004 16:28:41 +0200, Michael Nottebrock said:

> for putc_unlocked is buggy and wrongly detects putc_unlocked as missing in
> FreeBSD... guess there's nothing you can do about that. ;-)

We need to fix the check of course. Has it been reported to the
autoconf folks?

Werner



> --
> ,_, | Michael Nottebrock | lofi@freebsd.org
> (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
> \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
> _______________________________________________
> Gpa-dev mailing list
> Gpa-dev@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gpa-dev

On Monday 19 April 2004 17:03, Werner Koch wrote:
> On Mon, 19 Apr 2004 16:28:41 +0200, Michael Nottebrock said:
> > for putc_unlocked is buggy and wrongly detects putc_unlocked as missing
> > in FreeBSD... guess there's nothing you can do about that. ;-)
>
> We need to fix the check of course. Has it been reported to the
> autoconf folks?

At least not by me.

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

At Mon, 19 Apr 2004 16:54:37 +0200,
Michael Nottebrock wrote:
>
> [1 <text/plain; iso-8859-1 (quoted-printable)>]
> On Monday 19 April 2004 16:34, Marcus Brinkmann wrote:
>
> > This seems spurious. Maybe putc_unlocked is only defined as a macro
> > on BSD, and thus circumvents the autoconf tests? This would sound
> > broken to me (it may be allowed to define it as a macro, but it should
> > still be defined as a function in the library).
>
> Yes, it's a macro. However, I don't see what's wrong about that other than
> making autoconf's life harder.

putc_unlocked is specified as a function that may be defined as a
macro. The fact that it is defined as a macro does not relief you
from also declaring and defining it as a function. IE, the following
must be possible in a program:

#undef putc_unlocked
putc_unlocked ('a');

At least this is my interpretation of the wording in POSIX. In fact,
if you not only take into account the specification, but also the
application usage, it becomes apparent:


16064 APPLICATION USAGE
16065 Since they may be implemented as macros, getc_unlocked( ) and putc_unlocked( ) may treat
16066 incorrectly a stream argument with side effects. In particular, getc_unlocked(*f++) and
16067 putc_unlocked(*f++) do not necessarily work as expected. Therefore, use of these functions in
16068 such situations should be preceded by the following statement as appropriate:
16069 #undef getc_unlocked
16070 #undef putc_unlocked

The autoconf test relies on the function in the library object file.
This will work for almost all functions, except those for which POSIX
explicitely allows the lack of a function definition (like setjmp,
FD_CLR, etc).

Thanks,
Marcus

On Monday 19 April 2004 17:15, Marcus Brinkmann wrote:
> At Mon, 19 Apr 2004 16:54:37 +0200,
>
> Michael Nottebrock wrote:
> > [1 <text/plain; iso-8859-1 (quoted-printable)>]
> >
> > On Monday 19 April 2004 16:34, Marcus Brinkmann wrote:
> > > This seems spurious. Maybe putc_unlocked is only defined as a macro
> > > on BSD, and thus circumvents the autoconf tests? This would sound
> > > broken to me (it may be allowed to define it as a macro, but it should
> > > still be defined as a function in the library).
> >
> > Yes, it's a macro. However, I don't see what's wrong about that other
> > than making autoconf's life harder.
>
> putc_unlocked is specified as a function that may be defined as a
> macro. The fact that it is defined as a macro does not relief you
> from also declaring and defining it as a function.

It seems our standards guys agree and indeed FreeBSD 5 has putc_unlocked
defined in libc and the autoconf check does work there, too, so only FreeBSD
4.x is affected. I'm not sure if that's still worth the trouble of adding a
special case (in libassuan or autoconf).

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

At Mon, 19 Apr 2004 20:04:06 +0200,
Werner Koch wrote:
>
> On Mon, 19 Apr 2004 17:44:46 +0200, Michael Nottebrock said:
>
> > It seems our standards guys agree and indeed FreeBSD 5 has putc_unlocked
> > defined in libc and the autoconf check does work there, too, so only FreeBSD
> > 4.x is affected. I'm not sure if that's still worth the trouble of adding a
> > special case (in libassuan or autoconf).
>
> The autoconf check should indeed catch this for FreeBSD < 5.

The autoconf check (AC_CHECK_FUNCS) is not at fault. It does exactly
what it is supposed to do. If anything, we could hack in a special
check for FreeBSD based on the target OS to not check with
AC_REPLACE_FUNC, but hardwire HAVE_PUTC_UNLOCKED.

Thanks,
Marcus

On Mon, 19 Apr 2004 17:44:46 +0200, Michael Nottebrock said:

> It seems our standards guys agree and indeed FreeBSD 5 has putc_unlocked
> defined in libc and the autoconf check does work there, too, so only FreeBSD
> 4.x is affected. I'm not sure if that's still worth the trouble of adding a
> special case (in libassuan or autoconf).

The autoconf check should indeed catch this for FreeBSD < 5.

Werner

On Mon, 19 Apr 2004 19:58:48 +0200, Marcus Brinkmann said:

> The autoconf check (AC_CHECK_FUNCS) is not at fault. It does exactly
> what it is supposed to do. If anything, we could hack in a special
> check for FreeBSD based on the target OS to not check with
> AC_REPLACE_FUNC, but hardwire HAVE_PUTC_UNLOCKED.

Please do that. Although that gnupg 1.9 does currently not support
Slowaris etc. we should make it as easy as possible for the common
Free OSes. FreeBSD 4 is still in widespread use and if KDE runs on
it, gnupg 1.9 must be able to run there too.

Werner

On Monday 19 April 2004 16:46, Werner Koch wrote:
> On Mon, 19 Apr 2004 15:44:51 +0200, Michael Nottebrock said:
> > #include <sys/types.h> before #include <sys/socket.h> (this bug exists in
> > the local copies of libassuan in pinentry/dirmngr as well).
>
> pinentry uses a struipped down version of libassuan and dirmngr does
> not anymore source include libassuan. May it be that your versions
> are too old?

dirmngr does compile without any problems, but pinentry, even the latest
version from CVS, still contains a bogus check for fopencookie and bails
during configure stage if it isn't found.

Btw: The autogen.sh script fails with FreeBSD's /bin/sh:

if [. $(( `("$1" --version || echo "0") | cvtver` >= $2 )) == 1 ]
^
one too many


--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

On Monday 19 April 2004 22:17, I wrote:

> dirmngr does compile without any problems, but pinentry, even the latest
> version from CVS, still contains a bogus check for fopencookie and bails
> during configure stage if it isn't found.

I've checked out pinentry from CVS again and hacked at it until it compiled.

Diff attached.

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

On Tue, 20 Apr 2004 00:04:43 +0200, Michael Nottebrock said:

> I've checked out pinentry from CVS again and hacked at it until it compiled.

Aiihh. I fixed this on Jan 30 but obviously I forgot to commit it.
Please try the current CVS again.

Werner

On Tuesday 20 April 2004 07:08, Werner Koch wrote:
> On Tue, 20 Apr 2004 00:04:43 +0200, Michael Nottebrock said:
> > I've checked out pinentry from CVS again and hacked at it until it
> > compiled.
>
> Aiihh. I fixed this on Jan 30 but obviously I forgot to commit it.
> Please try the current CVS again.

My patches for assuan/mkerrors and secmem/secmem.c are still needed here.
Without the extra newline after the EOF in assuan/mkerrors, I get

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I/usr/local/include -Wall
-g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -c `test -f
'assuan-errors.c' || echo './'`assuan-errors.c
assuan-errors.c:94: syntax error before `-'

and without the extra typedef in secmem/secmem.c I get

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include -Wall -g -O2 -Wall
-Wcast-align -Wshadow -Wstrict-prototypes -c `test -f 'secmem.c' || echo
'./'`secmem.c
secmem.c: In function `secmem_dump_stats':
secmem.c:445: `ulong' undeclared (first use in this function)
secmem.c:445: (Each undeclared identifier is reported only once
secmem.c:445: for each function it appears in.)
secmem.c:445: syntax error before `poollen'

Patch attached.

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org

On Tue, 20 Apr 2004 11:20:51 +0200, Michael Nottebrock said:

> My patches for assuan/mkerrors and secmem/secmem.c are still needed here.
> Without the extra newline after the EOF in assuan/mkerrors, I get

Okay.

> and without the extra typedef in secmem/secmem.c I get

I solved that in a different way.

Please check out the latest CVS. If pinentry works for you I will do
a new release.

Thanks,

Werner

On Tuesday 20 April 2004 12:20, Werner Koch wrote:

> Please check out the latest CVS. If pinentry works for you I will do
> a new release.

Working now out of the box. Thanks!

--
,_, | Michael Nottebrock | lofi@freebsd.org
(/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org
\u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org