Project

General

Profile

Actions

Bug #2836

closed

Removal of /usr/include/regex.h needs to be loudly announced

Added by davshao over 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
08/08/2015
Due date:
% Done:

0%

Estimated time:

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.

Actions #1

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.

Actions #2

Updated by marino almost 9 years ago

  • Status changed from New to Closed

no feedback received ...

Actions

Also available in: Atom PDF