Issue #2836 has been updated by marino.
/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. ---------------------------------------- Bug #2836: Removal of /usr/include/regex.h needs to be loudly announced http://bugs.dragonflybsd.org/issues/2836#change-12730 * Author: davshao * Status: New * Priority: Normal * Assignee: * Category: * Target version: ---------------------------------------- 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. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
