www/redmine51 (ruby gem problem) DMSF plugin fails ld: error: unable to find library -lstdc++

gessel

gessel

I'm attempting to upgrade from www/redmine42-4.2.5 to www/redmine51-5.1.3_2 on FreeBSD 14.1-RELEASE-p3 GENERIC amd64 and I've used the redmine plugin DMSF which relies on xapian, specifically xapian-ruby (1.4.22). I can poudriere build and then install databases/ruby32-xapian-1.4.26 just fine, but the rake insists on building the gem, which does not go well.

ld: error: unable to find library -lstdc++

This is a known issue with code developed for Linux and ported and xapian-bindings seems to have code to deal with being built on FreeBSD, but for reasons that escape my skilz, it's not succeeding. The xapian project isn't responsible for the ruby gem, and there's one open issue in the xapian-ruby git, this exact issue.

I'm not finding anything comforting nor any obvious place to post a bug report, other than this fine resource. Anybody have any clues?

sh: 
/bin/sh ../libtool  --tag=CXX    --mode=link c++ -fno-strict-aliasing -Wall -Wno-unused -Wno-uninitialized -fvisibility=hidden -fvisibility-inlines-hidden
-I/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-core-1.4.22/include  -g -O2 -avoid-version -module -shrext ".so"
-L/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/lib -o _xapian.la -rpath /usr/local/lib/ruby/site_ruby/3.2/amd64-freebsd14 xapian_wrap.lo
/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-core-1.4.22/libxapian.la -lstdc++
libtool: link: c++  -fPIC -DPIC -shared -nostdlib /usr/lib/crti.o /usr/lib/crtbeginS.o  .libs/xapian_wrap.o   -Wl,-rpath
-Wl,/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-core-1.4.22/.libs -Wl,-rpath -Wl,/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/lib
-L/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/lib /usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-core-1.4.22/.libs/libxapian.so -lz -lrt -lstdc++ -L/usr/lib -lc++
-lm -lc -lgcc -lgcc_s /usr/lib/crtendS.o /usr/lib/crtn.o  -g -O2   -Wl,-soname -Wl,_xapian.so -o .libs/_xapian.so
ld: error: unable to find library -lstdc++
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make[3]: stopped in /usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-bindings-1.4.22/ruby
*** Error code 1

Stop.
make[2]: stopped in /usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-bindings-1.4.22/ruby
*** Error code 1

Stop.
make[1]: stopped in /usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-bindings-1.4.22
*** Error code 1

Stop.
make: stopped in /usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-bindings-1.4.22
rake aborted!
 
I set bundle config set --local without 'development test xapian' and DMSF installs fine without xapain, but having a decent full text search is a very nice to have feature and it was working just fine in previous versions. I found the latest git pull loads with no issues other than the xapain build problem.

I'm curious why the databases/ruby-xapian port isn't recognized; it builds fine on poudriere and installs, but

sh: 
# pkg version | grep xapian
php82-xapian-1.4.26                =
py311-xapian-1.4.26                =
ruby32-xapian-1.4.26               =
xapian-bindings-1.4.26             =
xapian-core-1.4.26,1               =
xapian-omega-1.4.26                =
# gem list | grep xapian
#
Other pkg installed gems do gem list as expected.

I tried pkg delete -f devel/gcc13-13.3.0 and removing xapian from without
checking for gcc... no
but got the same error, thanks covacat for the suggestion, although reviewing the previous build messages, the same status for GCC was reported even though devel/gcc13-13.3.0 was installed.
 
look at /usr/ports/databases/ruby-xapian/files/patch-configure
it seems that the gcc test if flawed and will add libstdc++ anyway so the patch removes it
 
Hi covacat, thanks for your help! I am sorry I dropped this to move on to the sftp module on the same server (thank you for your help there, very much appreciated). I'm installing this from Poudriere, so it's a bit more complicated to check the local ports directory, but from github, patch-configure reads:

Code: 
--- configure.orig    2023-02-02 01:01:44 UTC
+++ configure
@@ -21048,7 +21048,7 @@ SWIG_CXXFLAGS=
 if test yes = "$GXX" ; then
                     SWIG_CXXFLAGS="-fno-strict-aliasing"
 
-              XAPIAN_LIBS="$XAPIAN_LIBS -lstdc++"
+              XAPIAN_LIBS="$XAPIAN_LIBS"
 
 
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext

Checking the build directory on the install server, which is ignoring the installed pkg and building from source,
/usr/local/lib/ruby/gems/3.2/gems/xapian-ruby-1.4.22/xapian-bindings-1.4.22/configure
does not include this patch and reads at line 21047

Code: 
SWIG_CXXFLAGS=
if test yes = "$GXX" ; then
                    SWIG_CXXFLAGS="-fno-strict-aliasing"

              XAPIAN_LIBS="$XAPIAN_LIBS -lstdc++"


cat confdefs.h - <<_ACEOF >conftest.$ac_ext

It seems easy enough to patch the local build but shouldn't ruby check for installed gems before attempting to build? It also seems like xapian-bindings/configurecould be modified upstream to include conditional *BSD tests and not specify -lstdc++ where it won't work.

The FreeBSD port patches to enable building without error while Xapian-bindings 1.4.22 (2023-02-02): that gets installed doesn't.

The redmine_dmsf/Gemfiledoesn't seem to specify a version (and xapian-ruby isn't specified anywhere else):

Code: 
source 'https://rubygems.org' do
  gem 'ox' # Dav4Rack
  gem 'rake' unless Dir.exist?(File.expand_path('../../redmine_dashboard', __FILE__))
  gem 'uuidtools'
  gem 'zip-zip' unless Dir.exist?(File.expand_path('../../vault', __FILE__))

  # Redmine extensions
  unless Dir.exist?(File.expand_path('../../easyproject', __FILE__))
    gem 'active_record_union'
    gem 'simple_enum'
    group :xapian do
      gem 'xapian-ruby'
    end
  end
  unless %w[easyproject easy_gantt custom_tables]
         .any? { |plugin| Dir.exist?(File.expand_path("../../#{plugin}", __FILE__)) }
    group :test do
      gem 'rails-controller-testing'
    end
  end
end

though redmine/Gemfile.lock does specify xapian-ruby (1.4.22) and ports has ruby32-xapian-1.4.26.

Since 1.4.22 isn't installed (1.4.26 is by pkgs) maybe... editing (bad practice, I know) Gemfile.lock to 1.4.26 would recognize the installed package?
 
Just an update, this is a problem with roots back in digital prehistory - or nearly so, at least well before Clang. The Xapian team is looking at some fix options. There's at least one other project that has run into what looks like the same issue and has implemented an OS name conditional block, which is brute force and fragile in the face of OS forks, but given how rare such events are, might be a maintainable solution. I'll update again if/when a fix hits upstream.


Ooops, edit: ticket at Xapian project: https://trac.xapian.org/ticket/834
 
You must log in or register to reply here.
Back
Top