dirchownmod and savewd modules uses unavailable functions under Windows

2012-06-06 Thread Michael Goffioul
Hi, While compiling octave under MSVC with current gnulib, I got the following problems (leading undefined references at link stage): 1) dirchownmod uses fchown, but this is not available on Windows and there's no replacement in gnulib 2) savewd uses waitpid, but it doesn't have a dependency on g

Re: [PATCH] readme-release: require the promoted modules

2012-06-06 Thread Jim Meyering
Akim Demaille wrote: > Le 5 juin 2012 à 12:12, Jim Meyering a écrit : > >> Good idea. This has burned even me ;-) >> Please commit. > > EPERM. You should be able to push that, now.

Re: [PATCH] directory separator

2012-06-06 Thread Paul Eggert
On 06/06/2012 12:43 PM, John Darrington wrote: > If as you say, windows prefers \ is there a good reason NOT to use it? Mostly to avoid the maintenance hassle. Also, the change makes the code a bit bigger and slower even on non-Windows platforms.

Re: [PATCH] directory separator

2012-06-06 Thread John Darrington
On Wed, Jun 06, 2012 at 01:10:09PM -0600, Eric Blake wrote: On 06/06/2012 12:54 PM, John Darrington wrote: > I'm offering this patch which ensures that the paths of tempfiles are > created with the appropriate separator for the machine. What platform did you need it on?

Re: [PATCH] directory separator

2012-06-06 Thread Eric Blake
On 06/06/2012 12:54 PM, John Darrington wrote: > I'm offering this patch which ensures that the paths of tempfiles are > created with the appropriate separator for the machine. What platform did you need it on? Windows understands paths with /, even if it prefers \ as the canonical separator, an

[PATCH] directory separator

2012-06-06 Thread John Darrington
I'm offering this patch which ensures that the paths of tempfiles are created with the appropriate separator for the machine. J' -- PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://keys.gnupg.net or any PGP keyserver for public key.

Re: GNU sed version 4.2.1: on OS X, C locale gets aliased to UTF-8

2012-06-06 Thread Max Horn
Dear Paul, thank you for considering resolving this issue! Am 06.06.2012 um 16:53 schrieb Paul Eggert: > How about the following patch instead? Does it solve the problem? Yes, that also solves the problem (I just tested it). BTW, a very off-topic, very low importance remark: In your patch, a

Re: GNU sed version 4.2.1: on OS X, C locale gets aliased to UTF-8

2012-06-06 Thread Paul Eggert
How about the following patch instead? Does it solve the problem? I'd also like Bruno's opinion on this of course. --- a/lib/localcharset.c +++ b/lib/localcharset.c @@ -542,5 +542,12 @@ locale_charset (void) if (codeset[0] == '\0') codeset = "ASCII"; +#ifdef DARWIN7 + /* MacOS X sets M

Re: GNU sed version 4.2.1: on OS X, C locale gets aliased to UTF-8

2012-06-06 Thread Max Horn
PS: I should have clarified what Mac OS X version(s) I was talking about: The data reported in my email was from Mac OS X 10.6.8. Tonight, I'll compare this with a 10.5 machine of mine; and I could try get hold of a 10.4 machine, too, though this may have to wait a few days. On the other hand, I

Re: GNU sed version 4.2.1: on OS X, C locale gets aliased to UTF-8

2012-06-06 Thread Max Horn
Dear all, I subscribed to this list solely to respond to this thread, and hopefully help iron out issues caused by installing GNU sed on Mac OS X (regressions in behavior compared to the system's sed). My interest stems from that fact that I am the maintainer of the GNU sed package in the Fink