Bug #2836
closedRemoval of /usr/include/regex.h needs to be loudly announced
0%
Description
The removal of /usr/include/regex.h as a consequence of updating the regex library needs to be loudly announced, such as in UPDATING and on the user mailing list.
Software that used to do something like check for PCRE and if that fails check for a native regex library by searching for /usr/include/regex.h is now broken building. A prominent example of this is x11/xterm. In either dports or pkgsrc, try building xterm.
For the example of xterm, changing to enabling PCRE will probably fix the build. A more serious problem is that software that used to find DragonFly's native regex library will do something like dump core. An example of this is apparently pkgsrc's bmake, where one can see during its configuration that it is checking for regex.h. At least this is happening to me using latest 4.3-DEVELOPMENT and doing a full buildworld.
The change to the new regex library I believe should be treated as a flag day event, with users told to rebuild or obtain updated packages of all userland software.
Updated by marino about 9 years ago
/usr/include/regex.h was not removed.
xterm builds fine in dports, without pcre:
http://muscles.dragonflybsd.org/bulk/latest-per-pkg/xterm/320/bleeding-edge-potential.log
regex.h is detected during configure:
checking for regcomp... yes
checking for regular-expression headers... regex.h
Where is this coming from? The initial premise is wrong, so everything that follows is invalid.