[Xapian-tickets] [Xapian] #834: *BSD conditional to modify xapian-bindings/config.ac to suppress -lstdc++ library

[Xapian]

#834: *BSD conditional to modify xapian-bindings/config.ac to suppress -lstdc++
library
--------------------------+-------------------------------
 Reporter:  David Gessel  |             Owner:  Olly Betts
     Type:  defect        |            Status:  assigned
 Priority:  normal        |         Milestone:  1.4.27
Component:  Build system  |           Version:  1.4.22
 Severity:  normal        |        Resolution:
 Keywords:                |        Blocked By:
 Blocking:                |  Operating System:  FreeBSD
--------------------------+-------------------------------
Comment (by Olly Betts):

 I don't think FreeBSD ever needed `-lstdc++` explicitly linking.

 We hit this problem on OpenBSD nearly 20 years ago and found the solution
 of explicitly linking `-lstdc++` :

 https://lists.xapian.org/pipermail/xapian-
 discuss/2005-September/001153.html

 I think I worked out the underlying cause a little later but memory is
 hazy this far in the future.  It must be something to do with dynamically
 loading a C++ shared object (xapian's Python bindings) into a program
 written in C (the Python interpreter).  From the comment it seemed to be
 something the OpenBSD devs had chosen to do, but sadly I failed to add a
 reference to what that was.  Something in their C/C++ toolchain
 presumably.

 Rather than limit the change to just OpenBSD, it seemed reasonable to
 always add `-lstdc++` when the compiler was identified as GCC because it
 was harmless when not needed, and might conceivably be needed on another
 platform which nobody had tested on.  Testing for a platform by name is a
 potentially problematic approach - consider if somebody forked OpenBSD
 under a different name, we'd likely still want this (and that's not an
 entirely theoretical concern - e.g. dragonflybsd is a fork of FreeBSD).
 However new platforms are fairly rare and Xapian has been ported to most
 of the existing ones so in practice it's not such a bad approach.

 This change was several years before clang arrived on the scene (wikipedia
 says 2007 for initial release, but 2010 or so for C++ support to be
 usable).

 Somewhat unhelpfully but also somewhat understandably, clang deliberately
 impersonates GCC enough to trick autoconf into identifying it as GCC -
 they did this so it can be used to build existing projects without having
 to modify their build systems extensively.  This wasn't a problem for our
 OpenBSD fix initially, but then libc++ came along (I didn't trivially find
 an exact year, but first mention in a xapian commit message was 2015; it
 becoming the default C++ library for clang was more recent though I
 think).

 Now on FreeBSD, our configure identifies clang as GCC, so adds `-lstdc++`,
 but clang now uses libc++ by default and libstdc++ probably isn't even
 installed so the link fails (if libstdc++ was installed, the explicit link
 would probably be harmless, but may cause problems).

 We do actually already go on to poke the compiler harder to see if it's is
 really GCC or clang (or intel's compiler which similarly tries to trick
 configure into thinking it is GCC) but it wouldn't be correct to move this
 addition to only be done for GCC because clang can be built to use
 libstdc++ (and it can be even be built to allow selection of libc++ or
 libstdc++ at runtime).

 My recent testing on OpenBSD with the system clang shows that explicitly
 linking with libstdc++ fails (because libstdc++ isn't found) but not
 explicitly linking with libstdc++ also fails with:

 {{{
 <internal:/usr/local/lib/ruby/3.3/rubygems/core_ext/kernel_require.rb>:136:in
 `require': Cannot load specified object - /root/xapian-
 bindings/ruby/.libs/_xapian.so (LoadError)
         from
 <internal:/usr/local/lib/ruby/3.3/rubygems/core_ext/kernel_require.rb>:136:in
 `require'
         from /root/xapian-bindings/ruby/xapian.rb:42:in `<module:Xapian>'
         from /root/xapian-bindings/ruby/xapian.rb:40:in `<top (required)>'
         from
 <internal:/usr/local/lib/ruby/3.3/rubygems/core_ext/kernel_require.rb>:136:in
 `require'
         from
 <internal:/usr/local/lib/ruby/3.3/rubygems/core_ext/kernel_require.rb>:136:in
 `require'
         from ./smoketest.rb:29:in `<main>'
 }}}

 This is not the same as the original error in that old email thread, but
 it could plausibly be the same cause (and modern Ruby returns a clean
 `LoadError` while Python, or at least 20-year old Python, allowed a
 splurge of dynamic linker errors).

 Linking explicitly with `-lc++` or `-lc++abi` doesn't seem to fix this.  I
 haven't tried with Python instead of Ruby yet (now I've dug out the
 original email thread I see the original report was with Python).
-- 
Ticket URL: <https://trac.xapian.org/ticket/834#comment:5>
Xapian <https://xapian.org/>
Xapian