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
