Date: Mon, 22 Jan 2018 12:26:39 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Kyle Evans <kevans@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328240 - in head: etc/mtree lib lib/libc/regex lib/libc/tests/regex lib/libregex lib/libregex/tests share/mk Message-ID: <20180122102639.GD55707@kib.kiev.ua> In-Reply-To: <201801220244.w0M2if3I083081@repo.freebsd.org> References: <201801220244.w0M2if3I083081@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 22, 2018 at 02:44:41AM +0000, Kyle Evans wrote: > Author: kevans > Date: Mon Jan 22 02:44:41 2018 > New Revision: 328240 > URL: https://svnweb.freebsd.org/changeset/base/328240 > > Log: > Add libregex, connect it to the build > > libregex is a regex(3) implementation intended to feature GNU extensions and > any other non-POSIX compliant extensions that are deemed worthy. > > These extensions are separated out into a separate library for the sake of > not cluttering up libc further with them as well as not deteriorating the > speed (or lack thereof) of the libc implementation. > > libregex is implemented as a build of the libc implementation with LIBREGEX > defined to distinguish this from a libc build. The reasons for > implementation like this are two-fold: > > 1.) Maintenance- This reduces the overhead induced by adding yet another > regex implementation to base. > > 2.) Ease of use- Flipping on GNU extensions will be as simple as linking > against libregex, and POSIX-compliant compilations can be guaranteed with a > REG_POSIX cflag that should be ignored by libc/regex and disables extensions > in libregex. It is also easier to keep REG_POSIX sane and POSIX pure when > implemented in this fashion. You are doing very fragile and unmaintainable trick on all consumers there. Your libregex.so exports the same symbols under the same version as the libc does. In other words, we now provide two binary-incompatible callable symbols, and selection of the symbol by the consumer depends on the DT_NEEDED order and interposing. For instance, if some program loads a module linked to your libregex, the program behaviour suddenly changes. Since the library provides incompatible implementation, it must use different versions for the symbols, at least to save others time to debug the mess.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180122102639.GD55707>