[Bug hurd/11638] regex.c fails to compile on Hurd

[Bug hurd/11638] regex.c fails to compile on Hurd

[eggert at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

--- Comment #2 from Paul Eggert <eggert at gnu dot org> 2012-02-17 08:15:59 UTC ---
Created attachment 6224
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6224
* posix/regex_internal.h (MAX, MIN): Define if not already defined.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[eggert at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

Paul Eggert <eggert at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at gnu dot org

--- Comment #3 from Paul Eggert <eggert at gnu dot org> 2012-02-17 08:17:18 UTC ---
I have attached the patch that Gnulib uses for this problem: it's more
portable, as it doesn't assume that <sys/param.h> exists or that <sys/param.h>
defines MIN and MAX.  regex_internal.h is used outside glibc so it needs to be
a bit more portable.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

Thomas Schwinge <tschwinge at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tschwinge at sourceware dot
                   |                            |org

--- Comment #4 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-02-17 09:22:28 UTC ---
This had just come up on libc-alpha again:
<http://sourceware.org/ml/libc-alpha/2012-02/msg00324.html>.

I hadn't realized these are imported/shared files. (Shouldn't this be
mentioned somewhere prominently?)  In this case, we'd go with the
upstream fix, obviously.  But -- Paul, please have another look at your
MIN definition...  ;-P

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-02-17 13:08:42 UTC ---
On Fri, 17 Feb 2012, tschwinge at sourceware dot org wrote:

> I hadn't realized these are imported/shared files. (Shouldn't this be
> mentioned somewhere prominently?)  In this case, we'd go with the

I think gnulib's config/srclist.txt is the master list of files gnulib 
gets from elsewhere, including those it gets from glibc.  It's not perfect 
- as I previously noted, gnulib's getcwd.c appears to be from glibc but 
isn't listed there.  And, various entries therein are commented out with 
references to glibc bugs that are marked as FIXED - so whatever the 
current reasons for those files not being fully in sync with glibc, the 
lists of bugs in comments aren't particularly helpful.

I'd like to see these files more fully in sync between glibc and gnulib 
again (as I said in 
<http://sourceware.org/ml/libc-alpha/2012-01/msg00123.html>, the only 
differences that seem essential are the gnulib changes to license headers 
and gnulib's use of spaces instead of tabs for indentation, and those are 
presumably handled automatically by the gnulib mechanism for updating from 
external projects).  But as noted in 
<http://sourceware.org/ml/libc-alpha/2012-01/msg00129.html> and 
<http://sourceware.org/ml/libc-alpha/2012-01/msg00128.html> this does 
require gnulib maintainers to send lots of individual logical patches to 
resync things.

For the shared files, it's generally glibc that is supposed to be the 
master, not gnulib.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[eggert at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

Paul Eggert <eggert at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #6224|0                           |1
        is obsolete|                            |

--- Comment #6 from Paul Eggert <eggert at gnu dot org> 2012-02-20 21:17:57 UTC ---
Created attachment 6230
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6230
Corrected patch from gnulib

Thanks, Thomas, for catching the cut-and-paste bug in my previous patch.
Here is a revised version, which supersedes the old proposal.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[eggert at gnu dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

--- Comment #7 from Paul Eggert <eggert at gnu dot org> 2012-02-20 21:21:22 UTC ---
(In reply to comment #5)

> For the shared files, it's generally glibc that is supposed to be the 
> master, not gnulib.

I agree with everything in Joseph's comment, including the fact that
glibc is supposed to be the master.  I plead lack of time in trying
to bring things up to sync.  My current project is to sync the regex
code of glibc, gnulib, and Emacs, and at the rate I'm going it'll take
months, if not years, to finish.  Admittedly this may be the worst case
but still it'd be nice if we could make it easier to sync.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[tschwinge at sourceware dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11638

Thomas Schwinge <tschwinge at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Thomas Schwinge <tschwinge at sourceware dot org> 2012-11-04 14:39:51 UTC ---
Fixed as part of Roland's commit bea9b19322c77265033a068ac60c95a37e798a80
»Fix lots of bitrot for stub configurations.«:

    [...]

    * posix/regex.c: Include <sys/param.h> for MIN/MAX.

    [...]

In NEWS marked as fixed in commit
512a49be20d42af59968513cd5094b3918cf6663.


Conciliating the different versions of this regex implementation (which
Paul said he is working on) is a different matter.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug hurd/11638] regex.c fails to compile on Hurd

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11638

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug hurd/11638] New: regex.c fails to compile on Hurd

[aurelien at aurel32 dot net]

Since commit 54dd0ab31fe2b2168ba1a6180a0c05941fb54b3c, the MAX macro is used in 
regex_internal.c which is included by regex.c, while it is not defined on the 
include on Hurd.

On other architectures it is define in <sys/param.h> which is included in a 
weird way:

from ../sysdeps/i386/i686/hp-timing.h:25,
from ../sysdeps/x86_64/hp-timing.h:23,
from ../nptl/descr.h:28,
from ../nptl/sysdeps/x86_64/tls.h:98,
from ../include/tls.h:6,
from ../bits/libc-tsd.h:45,
from ../locale/localeinfo.h:210,
from regex.c:54

I think that it should be included directly in regex_internal.h instead. Patch 
will follow.

-- 
           Summary: regex.c fails to compile on Hurd
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: hurd
        AssignedTo: roland at gnu dot org
        ReportedBy: aurelien at aurel32 dot net
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: i686-unknown-gnu0.3
  GCC host triplet: i686-unknown-gnu0.3
GCC target triplet: i686-unknown-gnu0.3


http://sourceware.org/bugzilla/show_bug.cgi?id=11638

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug hurd/11638] regex.c fails to compile on Hurd

[aurelien at aurel32 dot net]

------- Additional Comments From aurelien at aurel32 dot net  2010-05-26 14:38 -------
Created an attachment (id=4818)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=4818&action=view)
Patch to fix the problem


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=11638

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.