Re: permissions on autom4te.cache/ ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 11/24/2009 7:44 AM: > The > mkdir "$cache", 0755 > > line has been in autom4te.in ever since that file was written. > OK to install? > > Cheers, > Ralf > > Let umask govern permissions for autom4te.cache directory. Looks fine to me, but it probably warrants a NEWS entry. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksMvqAACgkQ84KuGfSFAYA+2gCgk1OuW8AXqCrN/oZj98S+nJNM kJMAoMmMsKlOVYiUn6ZR6CTej/qG1WCG =MZoZ -END PGP SIGNATURE-
Re: Broken autoconf mmap test
Hi Eric,
* Eric Blake wrote on Tue, Nov 10, 2009 at 06:00:58AM CET:
> According to Corinna Vinschen on 11/9/2009 7:05 AM:
> > This part of the testcase
> >
> > data2 = (char *) malloc (2 * pagesize);
> > if (!data2)
> > return 1;
> > data2 += (pagesize - ((long int) data2 & (pagesize - 1))) & (pagesize -
> > 1);
> > if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
> >MAP_PRIVATE | MAP_FIXED, fd, 0L))
> > return 1;
> >
> > is bad. The chance that the address of data2 is not usable for mmap on
> > Windows/Cygwin is 100%. The problem here is that the generic HAVE_MMAP
> > test tests one certain feature, which is not usable on Windows, and which
> > is non-portable.
>
> MAP_FIXED appears to be more portable when the fixed address was obtained
> from a previous mmap call. Therefore, this patch fixes the macro as well
> as making diagnosing configure failures more accurately pinpoint why they
> are declaring failure. I don't have access to HP-UX 11, which is another
> platform where AC_FUNC_MMAP was failing; I would appreciate if someone
> else could see if this makes a difference there. But I have verified that
> this now sets HAVE_MMAP for cygwin 1.5.x and cygwin 1.7 where the old
> version failed, and that it does not change behavior on Linux or OpenBSD.
With this patch, the test exits with status 10 on HP/UX 11. Without the
patch, the failure is 1 and also happens at the
if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_FIXED, fd, 0L))
line. Not sure what to try next.
mmap(2) has several parts. The general part documents:
When MAP_FIXED is set in the flags argument, the implementation is
informed that the value of pa must be addr, exactly. If MAP_FIXED is
set, mmap() may return MAP_FAILED and set errno to EINVAL. If a
MAP_FIXED request is successful, the mapping established by mmap()
replaces any previous mappings for the process' pages in the range
[pa, pa+len].
[...]
Use of MAP_FIXED may result in unspecified behavior in further use of
brk(), sbrk(), malloc(), and shmat(). The use of MAP_FIXED is
discouraged, as it may prevent an implementation from making the most
effective use of resources.
The HP-UX extensions part documents:
If MAP_FIXED is set in flags:
+addr must be a multiple of the page size returned by
sysconf(_SC_PAGE_SIZE).
[...]
+The use of MAP_FIXED is strongly discouraged because it is
not portable. Using MAP_FIXED is generally unsuccessful on
this implementation, and when it is successful, it may
prevent the system from optimally allocating virtual address
space.
MAP_FIXED is discouraged, but there are some applications which by
design must fix pointer offsets into file data. The application must
map the file at a specific address in order for the file offsets
embedded in the file to make sense.
Cheers,
Ralf
> >From fb1f28a2ff2c688e63dc97ece7fde86e16864491 Mon Sep 17 00:00:00 2001
> From: Eric Blake
> Date: Mon, 9 Nov 2009 21:45:00 -0700
> Subject: [PATCH] Fix AC_FUNC_MMAP for cygwin.
>
> * lib/autoconf/functions.m4 (AC_FUNC_MMAP): Make the test more
> portable: Actually check for , and only use MAP_FIXED
> on an address previously returned from mmap.
> * THANKS: Update.
> Reported by Corinna Vinschen.
>/* Next, try to mmap the file at a fixed address which already has
> something else allocated at it. If we can, also make sure that
> we see the same garbage. */
>fd = open ("conftest.mmap", O_RDWR);
>if (fd < 0)
> -return 1;
> - data2 = (char *) malloc (2 * pagesize);
> - if (!data2)
> -return 1;
> - data2 += (pagesize - ((long int) data2 & (pagesize - 1))) & (pagesize - 1);
> +return 9;
>if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
>MAP_PRIVATE | MAP_FIXED, fd, 0L))
> -return 1;
> +return 10;
Re: permissions on autom4te.cache/ ?
[ adding autoconf-patches ]
Hello Harlan,
thanks for the report.
* Harlan Stenn wrote on Sat, Nov 14, 2009 at 08:28:18AM CET:
> I'm real careful to set my umask to 2, as it is Important that
> directories and files I create are able to be modified by others in the
> group.
>
> autom4te.cache/ is created with 755 perms.
>
> Is there a good reason why my umask is being ignored when this directory
> is being created?
>
> This is definitely going on with 2.59, 2.61, and 2.64.
The
mkdir "$cache", 0755
line has been in autom4te.in ever since that file was written. I'm not
sure why. Surely the user can just adjust her umask if she wants more
restrictive permissions, and should probably do so if she puts the cache
directory below, say, /tmp.
As a workaround, you should be able to just pre-create the cache
directory, or turn off caching altogether, see 'info Autoconf
"Customizing autom4te"'.
OK to install?
Cheers,
Ralf
Let umask govern permissions for autom4te.cache directory.
* bin/autom4te.in: Do not pass 0755 permissions to mkdir of
the cache directory.
Report by Harlan Stenn.
diff --git a/bin/autom4te.in b/bin/autom4te.in
index 2e7fc04..a51fa99 100644
--- a/bin/autom4te.in
+++ b/bin/autom4te.in
@@ -972,7 +972,7 @@ if ($freeze)
# We need our cache directory. Don't fail with parallel creation.
if (! -d "$cache")
{
-mkdir "$cache", 0755
+mkdir "$cache"
or -d "$cache"
or fatal "cannot create $cache: $!";
}
Re: Bug#557632: broken test for mmap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 11/24/2009 3:37 AM: >> what leads to not detecting mmap on Debian and because of this some >> packages fail to build (I did hit this on sdcv). > > Proposed patch. Fixes the test with CC=g++. OK to apply and add Michal > to THANKS? Yes, this looks reasonable. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksL13AACgkQ84KuGfSFAYBSewCgrlhWT7qqI1MMc7jI9QKu2ciP XkUAnAkmuXKpCkvTm/EG4QyeNufCzcEQ =no+1 -END PGP SIGNATURE-
Re: Bug#557632: broken test for mmap
tags upstream patch
thanks
Hello Michal,
thanks for the bug report. Adding autoconf-patches.
* Michal Čihař wrote on Mon, Nov 23, 2009 at 01:27:43PM CET:
> the mmap test currently present in autoconf fails to compile:
>
> conftest.cpp:154: warning: deprecated conversion from string constant to
> 'char*'
> conftest.cpp:157: error: invalid conversion from 'void*' to 'char*'
>
> what leads to not detecting mmap on Debian and because of this some
> packages fail to build (I did hit this on sdcv).
Proposed patch. Fixes the test with CC=g++. OK to apply and add Michal
to THANKS?
Cheers,
Ralf
Fix AC_FUNC_MMAP regression with C++ compiler in 2.65.
* lib/autoconf/functions.m4 (AC_FUNC_MMAP): Use const char*
for the constant string. Cast void* to char* for assignment.
* NEWS, THANKS: Update.
Report by Michal Čihař.
diff --git a/NEWS b/NEWS
index b72eb17..32fa957 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
GNU Autoconf NEWS - User visible changes.
+* Major changes in Autoconf 2.65a (-??-??) [experimental]
+ Released by
+
+** AC_FUNC_MMAP works in C++ mode again. Regression introduced in 2.64.
+
* Major changes in Autoconf 2.65 (2009-11-21) [stable]
Released by Eric Blake, based on git versions 2.64.*.
diff --git a/lib/autoconf/functions.m4 b/lib/autoconf/functions.m4
index 6b6e7fc..14a8cb9 100644
--- a/lib/autoconf/functions.m4
+++ b/lib/autoconf/functions.m4
@@ -1258,6 +1258,7 @@ int
main ()
{
char *data, *data2, *data3;
+ const char *cdata2;
int i, pagesize;
int fd, fd2;
@@ -1282,10 +1283,10 @@ main ()
fd2 = open ("conftest.txt", O_RDWR | O_CREAT | O_TRUNC, 0600);
if (fd2 < 0)
return 4;
- data2 = "";
- if (write (fd2, data2, 1) != 1)
+ cdata2 = "";
+ if (write (fd2, cdata2, 1) != 1)
return 5;
- data2 = mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2, 0L);
+ data2 = (char *) mmap (0, pagesize, PROT_READ | PROT_WRITE, MAP_SHARED, fd2,
0L);
if (data2 == MAP_FAILED)
return 6;
for (i = 0; i < pagesize; ++i)
Re: Portland Fortran compiler changing executable name
* Ralf Wildenhues wrote on Sun, Nov 15, 2009 at 03:03:48PM CET: > OK to commit this untested patch? No complaints, so I pushed this now (after 2.65, however). Cheers, Ralf > Add pgfortran to list of Fortran 95+ compilers. > > * lib/autoconf/fortran.m4 (_AC_F95_FC): Add pgfortran before > pgf95. > Based on report by Jeff Squyres.
