Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

#63381 closed defect (fixed)

grep @3.7_0: 'struct mcontext' has no member named '__ss' on Tiger/PPC

Reported by: evanmiller (Evan Miller) Owned by: Schamschula (Marius Schamschula)
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: tiger Cc: kencu (Ken), mascguy (Christopher Nielsen)
Port: grep

Description

:info:build sigsegv.c: In function 'sigsegv_handler':
:info:build sigsegv.c:940: error: 'struct mcontext' has no member named '__ss'

Looking at /usr/include/ppc/ucontext.h, it appears that Tiger does not use the double-underscore prefixes for its mcontext struct member names. This issue should probably be addressed in legacysupport.

System info:

:debug:sysinfo Mac OS X 10.4.11 (darwin/8.11.0) arch powerpc
:debug:sysinfo MacPorts 2.7.1
:debug:sysinfo Xcode 2.5
:debug:sysinfo SDK 10.4
:debug:sysinfo MACOSX_DEPLOYMENT_TARGET: 10.4

Full log to follow.

Attachments (1)

grep-tiger-ppc-main.log (126.8 KB) - added by evanmiller (Evan Miller) 2 months ago.

Download all attachments as: .zip

Change History (16)

Changed 2 months ago by evanmiller (Evan Miller)

Attachment: grep-tiger-ppc-main.log added

comment:1 Changed 2 months ago by Schamschula (Marius Schamschula)

I don't have access to legacy systems.

GitHub PRs are welcome.

comment:2 Changed 2 months ago by kencu (Ken)

this happens on the rare ports that use this header. I have so far patched it -- I did one within the past couple of months. It is so rare that I've not thought to put it in legacysupport, but I can think that over.

Let me see if I can recall where I last patched this.

Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:3 Changed 2 months ago by evanmiller (Evan Miller)

This message

https://lists.gnu.org/archive/html/bug-libsigsegv/2021-05/msg00000.html

indicates that things may work on legacy systems using the +libsigsegv variant. Trying it now....

comment:5 Changed 2 months ago by kencu (Ken)

ld64-97 does the fix as a reinplace on line 423 which is also fairly simple

https://github.com/macports/macports-ports/blob/master/devel/ld64/Portfile

Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:6 Changed 2 months ago by evanmiller (Evan Miller)

It looks like the +libsigsegv variant does not work as expected (all platforms). Grep now uses the --with-libsigsegv configure option instead of auto-detection. Will open a PR to reflect this (and crossing fingers it fixes the Tiger issue).

comment:7 Changed 2 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:8 Changed 2 months ago by evanmiller (Evan Miller)

Upstream bug report regarding --with-libsigsegv not working: https://lists.gnu.org/archive/html/bug-grep/2021-08/msg00033.html

Proposed fix for original struct member issue: https://github.com/macports/macports-ports/pull/11913

comment:9 Changed 2 months ago by evanmiller (Evan Miller)

Resolution: fixed
Status: assignedclosed

In 8a1f47761a82b9ba709fa6c2410de4f24871f420/macports-ports (master):

grep: Fix build on Tiger

Closes: #63381

comment:10 Changed 2 months ago by evanmiller (Evan Miller)

In 552eca3a26249bca4785c9c55bf18dd2cecff1a9/macports-ports (master):

grep: Fix +libsigsegv variant

See: #63381

comment:11 Changed 2 months ago by evanmiller (Evan Miller)

Update: while the provided struct-member-rename patch does allow grep to build, there may be unexpected run-time behavior. See discussion here:

https://lists.gnu.org/archive/html/bug-gnulib/2021-08/msg00132.html

10.4 therefore should require the +libsigsegv variant. I will offer up a patch when I have time.

comment:12 Changed 2 months ago by kencu (Ken)

I for one always think we should run the test suite, on everything, and I do that as much as possible.

Before we jump off to the variant, we (so far as I know) at this moment have no indication that the libsigsegv variant performs any better on Tiger than the non-libsigsegv variant, although we can hope it does for sure, and I look forward to hearing if it does. If it does, obviously preferred.

So being the tester kind of guy I am, it would be nice to know we are upgrading in some way and not trading for something even worse :>

BTW PTHREAD_RWLOCK_INITIALIZER was one of my first additions to legacy-support way back when. So it is there, for grep to use if desired, as i see you found the tests wanted it (I think).

The other function missing was mempcpy. I don't know if that exists in darwin, as per BigSur here:

% man mempcpy
No manual entry for mempcpy

But I see someone put together a workaround in this file for it, at least <https://android.googlesource.com/platform/external/elfutils/+/441f72d43a9b550baa779fc82f70816da5f74f0e/config-compat-darwin.h>. Not sure if the grep guys already took care of that for darwin or not, I didn't follow all the links in your email chain.

Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:13 Changed 2 months ago by kencu (Ken)

As an aside, running the test suite on certain software can be extremely enlightening. I ran it on the opencv software one time, and as I recall 21% of the tests passed, 79% failed.

So there is that :>

Last edited 2 months ago by kencu (Ken) (previous) (diff)

comment:14 Changed 2 months ago by evanmiller (Evan Miller)

Indeed, I'm seeing more failing gnulib tests using libsigsegv than without it. Good catch. I've sent my latest report to the gnulib mailing list.

The two tests that were failing without libsigsegv have to do with stack overflows. I presume this will be a rare condition in a seasoned code base like grep. (Usually happens when someone implements a recursive algorithm incorrectly.) So I feel fairly comfortable with the current solution.

The grep/gnulib folks have resolved the mempcpy issue. The test suite expected PTHREAD_RWLOCK_INITIALIZER, but grep itself doesn't require it.

comment:15 Changed 2 months ago by evanmiller (Evan Miller)

Anyone on Leopard/PPC is encouraged to try the gnulib patch here:

https://lists.gnu.org/archive/html/bug-gnulib/2021-08/msg00153.html

You should be able to apply it directly to the grep source.

Note: See TracTickets for help on using tickets.