[gentoo-user] Re: undefined symbol "...[abi:cxx11]" (was: Do we have any Blender build experts in the house?)

[David Haller]

Hello,

First of all, this has nothing to do with blender "per se" ...

On Sat, 28 May 2016, J. García wrote:
>El sáb, 28-05-2016 a las 17:26 -0600, J. García escribió:
>> BTW, eix won't help you here, I tried it, so the next step is to find
>> what provides the symbol 'Imf_2_1::Header::view', after some searches
>> with find and then google, I arrived at opencv(though not 100% sure),
>> so you might need to rebuild that and make sure(read the log) g++ is
>> being called with std=c++11. tracking this sort of stuff might be
>> tricky.
>I was left with the doubt if opencv was the package causing trouble,
>and it is not, so I searched a bit more in depth, and I have found the
>library you need to rebuild, it is libIlmImf.so, and this time I'm
>sure.
>
>Looking for the package:
>
>$ qfile /usr/lib64/libIlmImf.so 
>media-libs/openexr (/usr/lib64/libIlmImf.so)

*Hah* Learned something new, I've overlooked qfile so far :)

>Looking for the symbol: 
>
>$ readelf -s /usr/lib64/libIlmImf.so  | grep   '.*Header.*view.*'
>  1617: 000000000004a350    25 FUNC    GLOBAL DEFAULT   10
>_ZNK7Imf_2_16Header4viewB
>  2248: 0000000000049e60    25 FUNC    GLOBAL DEFAULT   10
>_ZN7Imf_2_16Header4viewB5
>
>So you need to: emerge --oneshot media-libs/openexr

Yes, BUT...

a) use c++filt / nm -C (see below)

b) Won't help unless you actually recompile/emerge openexr with
   -std=c++11 or -std=gnu++11 (or -std={c,gnu}++14 or greater).
   reemerging as per default with -std=c++98 or less (what's the
   default std for c++ in g++?) won't help.

Generally: for any symbol containing '[abi:cxxNN]' you need that lib
compiled with the CXX flag '-std=c++NN'. As far as I can see, the
symbol 'foo[abi:cxxNN]' also provides the plain symbol 'foo', so it's
downwards compatible.

Ok, you got a symbol + [abi:cxxNN]. Usually, the first part of the
symbol gives you a hint as to what lib could be involved. In this case
some lib with *Imf* (Symbols Q* are usually Qt stuff ;). Searching
online usually helps if you've no idea, but use c++filt too if the
symbol seems weird (see below). But in this case with "Imf" ...:

$ ls /usr/lib64/*Imf*
/usr/lib64/libIlmImf-Imf_2_1.so.21      /usr/lib64/libIlmImf.so
/usr/lib64/libIlmImf-Imf_2_1.so.21.0.0

$ equery belongs /usr/lib64/libIlmImf.so 
 * Searching for /usr/lib64/libIlmImf.so ... 
media-libs/openexr-2.1.0 (/usr/lib64/libIlmImf.so -> libIlmImf-Imf_2_1.so.21.0.0)
media-libs/openexr-2.1.0 (/usr/lib64/libIlmImf-Imf_2_1.so.21.0.0)

$ nm /usr/lib64/libIlmImf.so | grep 'Imf_2_1.*Header.*view'
0000000000049a40 T _ZN7Imf_2_16Header12previewImageEv
000000000003d5dc t _ZN7Imf_2_16Header14typedAttributeINS_14TypedAttributeINS_12PreviewImageEEEEERT_PKc.part.46
0000000000049980 T _ZN7Imf_2_16Header15setPreviewImageERKNS_12PreviewImageE
00000000000492c0 T _ZN7Imf_2_16Header4viewB5cxx11Ev
0000000000049a80 T _ZNK7Imf_2_16Header12previewImageEv
000000000003d5dc t _ZNK7Imf_2_16Header14typedAttributeINS_14TypedAttributeINS_12PreviewImageEEEEERKT_PKc.part.51
0000000000049ac0 T _ZNK7Imf_2_16Header15hasPreviewImageEv
0000000000049300 T _ZNK7Imf_2_16Header4viewB5cxx11Ev
$ nm -C /usr/lib64/libIlmImf.so | grep 'Imf_2_1::Header::view'
00000000000492c0 T Imf_2_1::Header::view[abi:cxx11]()
0000000000049300 T Imf_2_1::Header::view[abi:cxx11]() const
$ nm /usr/lib64/libIlmImf.so | c++filt | grep 'Imf_2_1::Header::view'
00000000000492c0 T Imf_2_1::Header::view[abi:cxx11]()
0000000000049300 T Imf_2_1::Header::view[abi:cxx11]() const

Ok, nm does not work on stripped stuff. But strings does:

$ strip /usr/lib64/libIlmImf.so
$ nm /usr/lib64/libIlmImf.so 
nm: /usr/lib64/libIlmImf.so: no symbols
$ strings /usr/lib64/libIlmImf.so | c++filt | grep 'Imf_2_1::Header::view'
Imf_2_1::Header::view[abi:cxx11]()
Imf_2_1::Header::view[abi:cxx11]() const

And so does readelf[4]:

$ readelf -sW /usr/lib64/libIlmImf.so | c++filt | grep 'Imf_2_1::Header::view'
  1565: 0000000000049300    64 FUNC    GLOBAL DEFAULT   10 Imf_2_1::Header::view[abi:cxx11]() const
  2178: 00000000000492c0    64 FUNC    GLOBAL DEFAULT   10 Imf_2_1::Header::view[abi:cxx11]()

(so, I already _DO_ have libIlmImf compiled with -std=c++11 or
-std=gnu++11, so I'm fine, but you're missing the '[abi:cxx11]', so
you need to recompile with -std=c++11/-std=gnu++11).

That's because I "default" by now to c++11 (and the extra CXXSTD var
is due to me starting to switch that (back and forth) before realising
the below).

$ grep CXX /etc/portage/make.conf
CXXSTD=" -std=c++11"
CXXFLAGS="$CFLAGS ${CXXSTD} "

BUT!

Some packages do not compile (yet) with c++11, and still need
c++98/gnu++98.

And some even seem to already need c++14 (mkvtoolnix). *Woah* After
realizing this and finding the stuff about the env-files (I love
gentoo for stuff like this!), I thought a moment... And ...

So, I've got a couple of env-files and use them for the packages that
need it.

First of all: I set the CPU-dependend stuff (-march, -O* etc. _AND
ONLY THAT_ (see below)) in CFLAGS in make.conf, then combine CFLAGS +
CXXSTD + whatever to my CXXFLAGS in make.conf (see above). And for
packages needing special handling I have this (use c++NN instead of
gnu++NN if you don't want to cater for GNU stuff, e.g. if you're
cross-compiling (too)).

==== /etc/portage/env/cxx98-flags ====
CXXFLAGS="$CFLAGS -std=gnu++98"
====

==== /etc/portage/env/cxx11-flags ====
CXXFLAGS="$CFLAGS -std=gnu++11"
====

==== /etc/portage/env/cxx14-flags ====
CXXFLAGS="$CFLAGS -std=gnu++14"
====

This is (of course) assuming you have "$CFLAGS" only specifying
machine stuff, not C-language specific stuff[0].

And then I just add stuff to /etc/portage/package.env as needed, e.g.

==== /etc/portage/package.env ====
[..]
media-libs/avidemux-core        cxx98-flags
media-video/avidemux            cxx98-flags
media-libs/avidemux-plugins     cxx98-flags
[..]
media-video/mkvtoolnix          cxx14-flags
[..]
====

As I default to c++11, I do not need openexr in there[3], but for you it
should be:

==== /etc/portage/package.env ====
media-libs/openexr              cxx11-flags
====

That whole scheme gives me at least a clean build (for e.g. avidemux
as well as mkvmerge/mkvtoolnix).

$ gcc-config -l
 [1] x86_64-pc-linux-gnu-4.9.3
 [2] x86_64-pc-linux-gnu-5.3.0 *

Once you've got that set up, it's basically like any package.use or
package.mask stuff, just add a

    foo/bar     cxxNN-flags

line to package.env, and get going ;)

I have to admit though, that I've no idea if you can state more than
one env-file on a line in package.env nor if you can somehow
include/source other env-files from others (say foo-flags sources
cxxNN-flags). I've just not have needed that yet, so I haven't tested
it.

HTH,
-dnh, still a noob to portage/ebuilds, but quite firm in building stuff

[0] If you need real C-specific flags, I'd suggest a variable in
    make.conf (-> c.f. CXXSTD in mine), say "OPT_FLAGS" (or ARCH_FLAGS
    for more specifics) for flags like "-O2 -march=.. ..." etc. and
    then e.g.

        CFLAGS="${OPT_FLAGS} -fsome_c_specific_gcc_flag_i_dont_know ..."
        CXXFLAGS="${OPT_FLAGS} ... -std=c++..."

    in make.conf and in the /etc/portage/env/cxx*-flags files use

        CXXFLAGS="${OPT_FLAGS} ... -std=c++..."

    as appropriate for each std you need in each "C++ std flags env
    file" ;) And use a similar approach for specific C-flags as well.

[3] which reminds me to prune any cxx11-flags

[4]
==== ~/bin/symgrep ====
#!/bin/sh
exec readelf -sW "$2" | c++filt | grep "$1"
====

-- 
MCSE: "Microsoft Certified Stupidity enclosed"        -- A. Spengler