[PATCHv2 2/2] pt_chown: break gnulib link dependency

If pt_chown calls ptsname(), then it must pull in gnulib; but then we must decide whether libtool is in use (libgnu.a vs. libgnu.la). Simpler is just shifting the burden to the sole caller. Even though this breaks compatibility with glibc pt_chown, we already document that our helper app is only c

[PATCHv2 1/2] grantpt: only build pt_chown when needed

Any platform (like Linux) that already has a working grantpt() does not need the headache of a pt_chown helper app. There's no point in offering pt_chown as a separate module, since the application has to be installed setuid to be useful, and even then, it is only useful to grantpt(). Distributin

Re: license relaxation request

On 10/19/2011 04:28 PM, Bruno Haible wrote: Hi Eric, Would you mind also relaxing the license on openpty() to LGPLv2+, now that all its components have been relaxed? This one is fine with me as well. Huh - in looking at that module, all the changes to lib/openpty.c are attributable to Brun

Re: pt_chown build failure

On 10/19/2011 04:33 PM, Bruno Haible wrote: Hi Eric, Also, I got a build failure when trying to use the grantpt module in libvirt: CCLD libgnu.la CC pt_chown.o make[4]: *** No rule to make target `libgnu.a', needed by `pt_chown'. Stop. Looks like the gnulib-tool output is not c

Re: pt_chown build failure

Hi Eric, > Also, I got a build failure when trying to use the grantpt module in > libvirt: > >CCLD libgnu.la >CC pt_chown.o > make[4]: *** No rule to make target `libgnu.a', needed by `pt_chown'. Stop. > > Looks like the gnulib-tool output is not considering the possibility of >

Re: license relaxation request

Hi Eric, > Would you mind also relaxing the license on openpty() to LGPLv2+, now > that all its components have been relaxed? This one is fine with me as well. Bruno -- In memoriam Jerzy Popiełuszko

pt_chown [was: license relaxation request]

On 10/19/2011 03:25 PM, Eric Blake wrote: Also, I got a build failure when trying to use the grantpt module in libvirt: CCLD libgnu.la CC pt_chown.o make[4]: *** No rule to make target `libgnu.a', needed by `pt_chown'. Stop. Looks like the gnulib-tool output is not considering the possibility o

[PATCH] pt_chown: use configmake to simplify build

Even with older automake, our configmake module provides the guarantee that pt_chown needs. * modules/pt_chown (Makefile.am): Drop line guaranteed by configmake. Signed-off-by: Eric Blake --- This is an alternative solution to: https://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00319.html

Re: license relaxation request

On 10/17/2011 05:58 PM, Bruno Haible wrote: Hi Eric, Can we relax the license of the following modules from LGPLv3+ down to LGPLv2+, so that libvirt can use them, and on the grounds that they are shipped as part of LGPLv2+ glibc? grantpt unlockpt pt_chown ptsname ttyname_r This is fine with

Re: enum vs int and API/ABI compatibility

Hi Simon, > silence C++ warnings ... > > typedef enum > { > ... > } Idna_rc; > ... > extern IDNAPI const char *idna_strerror (Idna_rc rc); > > ... allows future C++ code to be warning free. It was said that the root problem is that your idna_* functions return an 'int', but idna_strerro

Re: enum vs int and API/ABI compatibility

On 10/19/11 04:06, Simon Josefsson wrote: > 1) Is there any platform where this has any implications for the ABI? OS/400. libcurl ran into this problem; see . Android users are constantly worrying about wheth

Re: [PATCH] posix_openpt: new module

I ran gnulib's top-level "make check", and cppi spotted this: >From ca3be51f7beb529726b066d1da34acd338828b24 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 19 Oct 2011 15:28:46 +0200 Subject: [PATCH] posix_openpt: remove spurious #endif * lib/posix_openpt.c (posix_openpt): Remove spuriou

Re: I fixed this once already [Was Re: [PATCH] bootstrap: obey --no-git.]

Ping? On 8 Oct 2011, at 12:54, Gary V. Vaughan wrote: > Hi Paul, > > 2 month thread anniversary bump. Have you had the time to make a start on > anything yet? Is there anything I can do to help keep things moving? > > On 8 Sep 2011, at 01:56, Gary V. Vaughan wrote: >> Bumping this thread back

Re: [PATCH] Fix coreutils -Iintl vs gnulib gettext [WAS Re: a saner bootstrap script]

Gary V. Vaughan wrote: >> Jim, please consider pulling it into coreutils master as a better fix than >> twidding Makefiles after the fact in bootstrap.conf. >> >>> This -Iintl option will disappear with gettext version 0.19 - because >>> then "gettextize --intl" will not work any more; it's already

Re: enum vs int and API/ABI compatibility

Eric Blake writes: > On 10/19/2011 05:06 AM, Simon Josefsson wrote: >> This is not related to gnulib strictly, but I'd like to consult the >> wisdom on this list. I'm considering changing the argument to some >> functions in GNU Libidn from 'enum' to 'int' to silence C++ warnings >> (see [1] for

Re: a saner bootstrap script

Ping? On 16 Oct 2011, at 12:50, Gary V. Vaughan wrote: > Hi Jim, > > On 16 Oct 2011, at 04:15, Jim Meyering wrote: >> Gary V. Vaughan wrote: >>> Is there anything else I can do to help you incorporate this, and the >>> matching bootstrap.conf I wrote for you into coreutils now that the >>> releas

[PATCH] Fix coreutils -Iintl vs gnulib gettext [WAS Re: a saner bootstrap script]

Ping? On 16 Oct 2011, at 18:28, Gary V. Vaughan wrote: > On 16 Oct 2011, at 15:58, Bruno Haible wrote: >> Gary V. Vaughan wrote: >>> If there is a bug in gnulib-tool, or autopoint that puts unnecessary >>> 'intl/' references into Makefiles when the presence of >>> AM_GNU_GETTEXT_VERSION in configu

[PATCH] maint.mk: Respect $(build_aux) in web-manual rule.

* top/maint.mk (web-manual): Find gen-announce script in user's $(build_aux) directory instead of hard-coding 'build-aux'. --- ChangeLog|6 ++ top/maint.

Re: enum vs int and API/ABI compatibility

On 10/19/2011 05:06 AM, Simon Josefsson wrote: This is not related to gnulib strictly, but I'd like to consult the wisdom on this list. I'm considering changing the argument to some functions in GNU Libidn from 'enum' to 'int' to silence C++ warnings (see [1] for discussion). The change I'm con

Re: [PATCH] posix_openpt: new module

On 10/19/2011 03:50 AM, Bruno Haible wrote: Hi Eric, This module fails to build on several platforms. On AIX 5.1: test-posix_openpt.c:24: error: 'posix_openpt' undeclared here (not in a function) Thanks for fixing that. 2011-10-19 Bruno Haible posix_openpt: Fix compilation error.

enum vs int and API/ABI compatibility

This is not related to gnulib strictly, but I'd like to consult the wisdom on this list. I'm considering changing the argument to some functions in GNU Libidn from 'enum' to 'int' to silence C++ warnings (see [1] for discussion). The change I'm considering is from: typedef enum { ... } Idn

Re: [PATCH] posix_openpt: new module

Hi Eric, This module fails to build on several platforms. On AIX 5.1: test-posix_openpt.c:24: error: 'posix_openpt' undeclared here (not in a function) test-posix_openpt.c: In function 'main': test-posix_openpt.c:45: warning: implicit declaration of function 'posix_openpt' make: 1254-004 The er

Re: porting to NeXTstep

Hi Daniel, > * With this, a *lot* more things are working now. Good to hear; if the problems were sounding insurmountable you would be entirely on your own. > In fact, the only > breakage still in gllib is strcoll(), due to this platform's odd > three-argument form of it. (Could you point