nm --defined-only /usr/lib64/libglib-2.0.a |grep pcre # nm --defined-only /usr/lib64/libglib-2.0.a |grep pcre pcre_maketables.o: 0000000000000000 T pcre_maketables pcre_chartables.o: 0000000000000000 R _pcre_default_tables [...] Add --with-pcre=system to enable system pcre. Glib needs utf-8 support, so DEPEND on dev-libs/libpcre[unicode]
No, it should not use the system pcre. glib shipped pcre is patched for glib use, making it use glib's own UTF-8 tables, instead of pcre ones, therefore reducing overhead of it or something like that.
libpcre is needed for almost everything, so having glib use the same .so as everybody else will hurt not a bit in that regard. And then there's the obvious security benefits - next time libpcre gets a vuln, we'll only need to fix one library. Debian uses system pcre too, FWIW.
FWIW, we've been switching back and forth between the system pcre and the shipped pcre every 6 months... Could we try _not_ to change for once?
(In reply to comment #3) > FWIW, we've been switching back and forth between the system pcre and the > shipped pcre every 6 months... > > Could we try _not_ to change for once? > btw, the overlay[1] now forces usage of internal pcre (explicitly the old behaviour) till this bug is resolved 1. http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=commit;h=3912e9b77f0b31f29335948971dc9a335cbdcc2a
(In reply to comment #4) > (In reply to comment #3) > > FWIW, we've been switching back and forth between the system pcre and the > > shipped pcre every 6 months... > > > > Could we try _not_ to change for once? > > > > btw, the overlay[1] now forces usage of internal pcre (explicitly the old > behaviour) till this bug is resolved Please revert that
AArgh, I can't read. Thanks, for making it use internal pcre again. That's what I wanted, nevermind my comment
Trying to compile syslog-ng-3.0.1 failed on my system because Glib-2.16.6 (merged from official and stable branch) was compiled with internal pcre : admin ~/pkg/syslog-ng/work $ ../syslog-ng-3.0.1/configure checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for a BSD-compatible install... /usr/bin/install -c [...] syslog-ng Open Source Edition 3.0.1 configured Compiler options: compiler : gcc compiler options : -g -O2 -Wall -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/eventlog -D_BSD_SOURCE -D__BSD_SOURCE -D__FAVOR_BSD -DHAVE_NET_ETHERNET_H -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 linker flags : prefix : /usr/local Features: Sun STREAMS support : no Sun Door support : no Debug symbols : no GCC profiling : no Memtrace : no IPV6 support : yes spoof-source support : yes tcp-wrapper support : yes SSL support : yes SQL support : no Linux capability support : yes PCRE support : yes Env wrapper support : no admin ~/pkg/syslog-ng/work $ make make all-recursive make[1]: Entering directory `/home/admin/pkg/syslog-ng/work' Making all in src make[2]: Entering directory `/home/admin/pkg/syslog-ng/work/src' [...] gcc -g -O2 -Wall -o syslog-ng main.o libsyslog-ng.a -lrt -lnsl -Wl,-Bstatic -lfl -lglib-2.0 -levtlog -lssl -lcrypto -lz -lnet -lwrap -lcap -lpcre -Wl,-Bdynamic -ldl /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libpcre.a(pcre_globals.o):(.bss+0x0): multiple definition of `pcre_callout' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libglib-2.0.a(pcre_globals.o):(.bss+0x0): first defined here collect2: ld returned 1 exit status make[2]: *** [syslog-ng] Error 1 make[2]: Leaving directory `/home/admin/pkg/syslog-ng/work/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/admin/pkg/syslog-ng/work' make: *** [all] Error 2 IMHO, this is why USE flags exit. I just add 'external-pcre' to IUSE and a line 'use external-pcre && myconf="--with-pcre=system"' to src_compile() function in Glib's ebuild. No need anymore to switch back and forth, it's up to the user to decide to build Glib whitout internal pcre, or at least to other ebuilds' mainteners to inform the user that their ebuild won't compile if built with. Beside, I don't know if this issue just concerns syslog-ng-3.0.1 due to bad coding or if almost every packages that use both libpcre and Glib would failed to compile.
for some reason, you appear to be using the static glib library and also building stuff manually in /usr/local which is not of portage's responsability.
I'm not complaining about 'portage can't build my stuff', I'm just saying 'let the user choose if he want Glib's pcre support to be external or internal', which it's exactly the kind of situation which have made me choose Gentoo.
hu no, not exactly. Like flameeyes explained in his blog external libs should always be prefered. Keeping internal ones is the exception and glib has currently a good enough reason to stick to this way. That's what this bug is about.
syslog-ng has to link against static glib. This is the primary reason we actually ship a static library from glib system package as well. However the pcre symbols from the internal copy in glib should not be visible to glib users, but that's a bit tricky to hide in the static library I think... Anyway, if the problem is the static library exposing pcre symbols, then that is a somewhat different bug and should be treated in a separate entry imho.
(In reply to comment #11) > syslog-ng has to link against static glib. This is the primary reason we > actually ship a static library from glib system package as well. > However the pcre symbols from the internal copy in glib should not be visible > to glib users, but that's a bit tricky to hide in the static library I think... > Anyway, if the problem is the static library exposing pcre symbols, then that > is a somewhat different bug and should be treated in a separate entry imho. I'm running into exactly the same problem as Julien. I'm trying to build a local copy of syslog-ng 3.0.1 (it has some improvements over 2.x that are important to me), and it hits this issue with the PCRE symbols in glib. So if the solution is to hide those symbols in the static glib, then let me know if you'd like me to file a separate bugreport for it.
Adding "--enable-dynamic-linking" to configure args is enough to build rsyslog. No needs to touch glib.
Sorry. Typo. syslog-ng
glib in Debian an even in Archlinux pulls external pcre, you really should look how they fixed this problem.
This should probably done in overlay at first for testing purposes :/
dev-libs/glib-2.48.0 compiles with external libpcre (.so results 10% smaller) and works as I can see. Maybe adding system-pcre useflag disabled by default - for testing for those, who want?
Upstream is defaulting to system lib: --with-pcre=[internal/system] whether to use system PCRE [default=system] Hence, I would simply do the same for the next bump
done in 2.48.1
