[MDEV-17868] mysqltest fails to link with system PCRE libraries Created: 2018-11-28  Updated: 2019-01-24  Resolved: 2019-01-24

Status: Closed
Project: MariaDB Server
Component/s: Compiling
Affects Version/s: 10.2.15, 10.2.19
Fix Version/s: 10.1.38, 10.0.38, 10.2.22, 10.3.13

Type: Bug Priority: Major
Reporter: Chris Ross Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux

Attachments: Text File mariadb-pcre-link-order.patch    

 Description   

We have a custom linux environment. The system PCRE was recently updated to 8.42, and mariadb now detects that it has a pcre_stack_guard and tries to use it.

However, when building clients/mysqltest, it fails to link saying:

[ 95%] Linking CXX executable mysqltest
 
/usr/lib/../lib/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regfre
 
e':
 
pcreposix.c:(.text+0xf8): undefined reference to `pcre_free'
 
/usr/lib/../lib/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regcom
 
p':
 
pcreposix.c:(.text+0x1b9): undefined reference to `pcre_compile2'
 
pcreposix.c:(.text+0x205): undefined reference to `pcre_fullinfo'
 
/usr/lib/../lib/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regexe
 
c':
 
pcreposix.c:(.text+0x38a): undefined reference to `pcre_exec'
 
collect2: error: ld returned 1 exit status

I have found that changing the order of the pcre and pcreposix libraries will resolve this issue. As pcreposix clearly needs pcre, I think the order specified in client/CMakeLists.txt is wrong. pcreposix should be specified before pcre, so the linker knows to load needed symbols from prce.

(I don't know why this fails with our system libpcre, and doesn't fail when linking against the bundled pcre. If there is another solution for us at the system level, feel free to suggest).

 Comments   
Comment by Chris Ross [ 2018-12-03 ]

Anyone have any thoughts on this? I was hoping to hear feedback from someone in the mariadb dev process.

Thanks.

Comment by Sergei Golubchik [ 2018-12-05 ]

could you show the complete line used for linking? The one that fails. Run make VERBOSE=1 to see it

Comment by Chris Ross [ 2018-12-05 ]

Sure. Here ya go

[ 97%] Linking CXX executable mysqltest
 
cd /work/mariadb-i386/mariadb-10.2.15/client && /usr/bin/cmake -E cmake_link_script CMakeFiles/mysqltest.dir/link.txt --verbose=1
 
/usr/bin/c++   -m32 -pie -fPIC -Wl,-z,relro,-z,now -fstack-protector --param=ssp-buffer-size=4 -fno-rtti -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF  -Wl,--export-dynamic CMakeFiles/mysqltest.dir/mysqltest.cc.o  -o mysqltest  -lpthread ../libmariadb/libmariadb/libmariadbclient.a ../mysys/libmysys.a -lpcre -lpcreposix -lpthread -liconv ../dbug/libdbug.a ../mysys_ssl/libmysys_ssl.a ../mysys/libmysys.a ../dbug/libdbug.a ../mysys_ssl/libmysys_ssl.a -lm ../zlib/libzlib.a -ldl -lssl -lcrypto ../strings/libstrings.a -lpthread 
/usr/lib/../lib/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regfree':
 
pcreposix.c:(.text+0xf8): undefined reference to `pcre_free'
 
/usr/lib/../lib/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regcomp':
 
pcreposix.c:(.text+0x1b9): undefined reference to `pcre_compile2'
 
pcreposix.c:(.text+0x205): undefined reference to `pcre_fullinfo'
 
/usr/lib/../lib/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regexec': pcreposix.c:(.text+0x38a): undefined reference to `pcre_exec'
 
collect2: error: ld returned 1 exit status
 
make[6]: *** [client/CMakeFiles/mysqltest.dir/build.make:107: client/mysqltest] Error 1

Comment by Chris Ross [ 2018-12-05 ]

I realized upon pasting that that it's a cross-compile to i386. I'd earlier checked that the same situation exists in both ways we compile it, here is the native x86_64 link error as well.

[ 90%] Linking CXX executable mysqltest
 
cd /work/mariadb-x86_64/mariadb-10.2.15/client && /usr/bin/cmake -E cmake_link_script CMakeFiles/mysqltest.dir/link.txt --verbose=1
 
/usr/bin/c++    -pie -fPIC -Wl,-z,relro,-z,now -fstack-protector --param=ssp-buffer-size=4 -fno-rtti -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF  -Wl,--export-dynamic CMakeFiles/mysqltest.dir/mysqltest.cc.o  -o mysqltest  -lpthread ../libmariadb/libmariadb/libmariadbclient.a ../mysys/libmysys.a -lpcre -lpcreposix -lpthread -liconv ../dbug/libdbug.a ../mysys_ssl/libmysys_ssl.a ../mysys/libmysys.a ../dbug/libdbug.a ../mysys_ssl/libmysys_ssl.a -lm ../zlib/libzlib.a -ldl -lssl -lcrypto ../strings/libstrings.a -lpthread
 
/usr/lib/../lib64/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regfree':
 
pcreposix.c:(.text+0x127): undefined reference to `pcre_free'
 
/usr/lib/../lib64/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regcomp':
 
pcreposix.c:(.text+0x1f0): undefined reference to `pcre_compile2'
 
pcreposix.c:(.text+0x25c): undefined reference to `pcre_fullinfo'
 
/usr/lib/../lib64/libpcreposix.a(libpcreposix_la-pcreposix.o): In function `regexec':
 
pcreposix.c:(.text+0x459): undefined reference to `pcre_exec'
 
collect2: error: ld returned 1 exit status
 
make[5]: *** [client/CMakeFiles/mysqltest.dir/build.make:107: client/mysqltest] Error 1

Comment by Sergei Golubchik [ 2018-12-07 ]

Okay. Looks plausible. In my builds, libpcre and libpcreposix are dynamic libraries, so the dynamic linker knows that libpcreposix needs libpcre and the order doesn't really matter. If I build with the bundled pcre, it builds only static libpcre.a and libpcreposix.a libraries, but in this case CMake knows that libpcreposix needs libpcre and it always appends libpcre.a to the linker line whenever it sees libpcreposix.a there.

Clearly, when one has system static pcre libraries, neither from the above can help, and the linker complains.

Comment by Chris Ross [ 2019-01-03 ]

Hello. Is there any timeline for getting this changed in the trees? Specifically, I'll need to know which releases have this change, so that I can remove the local patch that I've put into our internal build system.

Thanks.

Generated at Thu Feb 08 08:39:43 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.