ferret.so: undefined symbol: _ZNSt7__cxx1119basic_ostringstreamIcSt11char_traitsIcESaIcEEC1Ev

[fingolfin]

... happens in some of our CI tests, namely for Julia 1.4 and 1.5 on Linux (but not for 1.6, nor on macOS), as @fieker and @GDeFranceschi pointed out to me.

I did not yet have time to investigate, but I strongly suspect that this is another instance of oscar-system/GAP.jl#553

That is: we compile ferret (a GAP package) on the user's system (here: the CI servers), using the C++ compiler installed there; but when loading it, it won't get linked the C++ library of that compiler, but rather against the one which is already loaded, namely the one bundled with Julia.

That would then explain why it works on macOS (there Julia does not bundle its own C++ standard library), and in Julia 1.6 (which I suspect bundles a newer C++ library, but have not verified that theory).

[benlorenz]

That symbol is exactly the same as oscar-system/Polymake.jl#251, so you might be able to fix it by replacing all std::ostringstream oss; by std::ostringstream oss("");. Only the empty constructor needs GLIBCXX_3.4.26 when built with a new libstdc++ version (gcc >= 9).
(not really a fix but a workaround that is already in use in libpolymake_julia and in libcxxwrap_julia)

[ThomasBreuer]

As far as I understand the situation, the error comes from the call GAP.Packages.load("ferret", install = true) in Oscar.jl/experimental/GaloisGrp/GaloisGrp.jl. In this call, we leave the installation/compilation to a GAP function (InstallPackage), hence the proposed workaround is not applicable.

(I cannot reproduce the problem with Julia 1.5 on my Linux notebook, perhaps this machine has a too new C++ library.)

[thofma]

Why is it not applicable? Is it not possible to apply the patch of @benlorenz upstream, that is, directly in the ferret package?

[fieker]

On Thu, Feb 04, 2021 at 01:16:34PM -0800, ThomasBreuer wrote: As far as I understand the situation, the error comes from the call `GAP.Packages.load("ferret", install = true)` in `Oscar.jl/experimental/GaloisGrp/GaloisGrp.jl`. In this call, we leave the installation/compilation to a GAP function (`InstallPackage`), hence the proposed workaround is not applicable. (I cannot reproduce the problem with Julia 1.5 on my Linux notebook, perhaps this machine has a too new C++ library.)

See #262

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #262 (comment)

[fingolfin]

We can ask the ferret author to apply the patch and make a release and hope that helps.

But it is otherwise difficult to apply the patch, as we invoke the GAP package manager to install ferret; to patch the ferret source, we'd first have to patch (hack) that package manager to allow us to insert code at the point we need.

Not impossible of course, but tricky and fragile.

Proper solution still would be a gap_ferrer_jll, see oscar-system/GAP.jl#614 -- that said, I am open for an interim solution.

[fingolfin]

I am going to submit a PR for ferret and ask @ChrisJefferson whether he can make a fresh release

[benlorenz]

Maybe someone (who can reproduce the issue) can try that workaround locally first? There might be other symbols with the same issue as well...

[fingolfin]

Indeed. I can reproduce it on an Ubuntu 20.04 box, and verified that gap-packages/ferret#40 resolves the issue there.

[thofma]

I just rerun CI here: https://github.com/oscar-system/Oscar.jl/pull/265/checks?check_run_id=1846286217

"#I Retrieving PackageInfo.g from https://gap-packages.github.io/ferret/PackageInfo.g "

The file says 1.0.4, but it is still downloading 1.0.3. Is this normal?

[fingolfin]

That seems like a temporary glitch (some cache somewhere not yet updated). I've re-run test of another PR, and there it passed.

It also works fine on my Ubuntu 20.20 machine now with ferret 1.0.4.

Unfortunately, now I run into errors on a bunch of other machines (including nenekiki here in KL), already during precompilation:

[ Info: Compiling JuliaInterface ...
#W dlopen() error: /tmpbig/horn/julia-1.5.3/bin/../lib/julia/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /users/cip/alggeom/horn/.julia/gaproot/v4.11/pkg/ferret-1.0.4/bin/x86_64-pc-linux-gnu-julia64-kv7/ferret.so)

[thofma]

I think what you see is the usual oscar-system/GAP.jl#553.

But the original issue seems to be fixed on GHA.

[fingolfin]

True.

[benlorenz]

There seems to be one more std::ostringstream() in ferret that was missed:
https://github.com/gap-packages/ferret/blob/master/YAPB%2B%2B/source/library/info.hpp#L20
I don't really know when #ifdef GAP_COMPILED_H is active, but I still get the symbol with ferret 1.0.4.

[ChrisJefferson]

woops, will investigate

[ChrisJefferson]

New release (v1.0.5) released. That code is enabled exactly when you are using GAP (this package can be used as a standalone program, without GAP).

[benlorenz]

Thanks for the quick fix, looks good on my machine now:

julia> GAP.Packages.load("ferret", install = true)
Error: Cannot load 'Ferret' due to missing binary library
Please run './configure; make' in the 'pkg/ferret' directory
#I  Getting PackageInfo URLs...
#I  Retrieving PackageInfo.g from https://gap-packages.github.io/ferret/PackageInfo.g ...
#I  Downloading archive from URL https://github.com/gap-packages/ferret/releases/download/v1.0.5/ferret-1.0.5.tar.gz ...
#I  Saved archive to /tmp/tmM4cnaq/ferret-1.0.5.tar.gz
#I  Extracting to /software/julia/depots/julia-153/gaproot/v4.11/pkg/ferret-1.0.5 ...
#I  Checking dependencies for ferret...
#I    GAPDoc >= 1.5: true
#I  Running compilation script on /software/julia/depots/julia-153/gaproot/v4.11/pkg/ferret-1.0.5 ...
true

julia> 

(Slightly confused why the previous fix did work elsewhere)

[thofma]

Thanks a lot @ChrisJefferson (and thanks @benlorenz for checking).

[fingolfin]

Thanks @ChrisJefferson

I am still confused as to how/why 1.0.4 then was working for me, and also in GitHub Actions? Odd.

[benlorenz]

I am still confused as to how/why 1.0.4 then was working for me, and also in GitHub Actions? Odd.

It might be because of CompilerSupportLibraries_jll (CSL_jll) which brings a more recent libstdc++. But depending on which packages are loaded in what order there might be the old julia libstdc++ or the new one from CSL_jll in the current process.
(I tried with just GAP and not with Oscar where e.g. Polymake.jl would pull in CSL_jll)

Thinking about that, adding CompilerSupportLibraries_jll and using it in GAP.jl might have fixed this issue as well, at least for most cases. Unless some other package that also relies on libstdc++, but does not depend on CSL_jll, is loaded first.