Summary: | grep core dumped on search of /usr/src | ||
---|---|---|---|
Product: | Base System | Reporter: | Zak <zsnafzig> |
Component: | bin | Assignee: | Kyle Evans <kevans> |
Status: | Closed FIXED | ||
Severity: | Affects Some People | CC: | emaste, pstef |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | Any | ||
OS: | Any |
Description
Zak
2017-09-14 17:57:30 UTC
I'll dig into this when I get some time. In the meantime, if it's feasible, this doesn't occur when compiled WITHOUT_BSD_GREP_FASTMATCH; those bits tend to be a little bit buggy still, unfortunately (=() and I'd really like to do away with them. Is it reasonable to just switch BSD_GREP_FASTMATCH to default no at this point? I switched BSD_GREP_FASTMATCH to default to no in my WIP branch and then the build fails: /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/tmp/usr/bin/ld: error: undefined symbol: tre_fastncomp >>> referenced by grep.c:764 (/scratch/tmp/emaste/freebsd/usr.bin/grep/grep.c:764) >>> grep.o:(main) /scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/tmp/usr/bin/ld: error: undefined symbol: tre_fastexec >>> referenced by util.c:474 (/scratch/tmp/emaste/freebsd/usr.bin/grep/util.c:474) >>> util.o:(procline) (In reply to Ed Maste from comment #2) I'm thinking so. I was afraid that libgnuregex might have more bugs that we hadn't uncovered that will popup when TRE isn't covering some of the more basic expressions, but it occurs to me now that we switched -HEAD to default GNU_GREP_COMPAT to 'no' so that's a non-issue. (In reply to Ed Maste from comment #3) Huh? That makes no sense. =( Is this WITH_META_MODE or something else that might have goofed it up? The first referenced line (grep.c:764) is behind an #ifndef WITHOUT_FASTMATCH, which is put in CFLAGS at Makefile:24 if MK_BSD_GREP_FASTMATCH != "yes" (In reply to Kyle Evans from comment #4) Sigh, this was due to stale object files. I thought I had cleaned out objdir first but it seems not. FASTMATCH is gone |