OS-X: libstdc++ problem.

[Chris Barker]

So I'm not sure this is really a conda-forge problem, but I get it when I try to build my code in an environment that is primarily conda-forge packages.

And the exact same build has worked for years in and outside of conda.

here's the error:

    import cy_basic_types # make sure it's imported, for the C++ lib

ImportError: dlopen(gnome/cy_gnome/cy_basic_types.so, 2): Symbol not found: __ZNKSt5ctypeIcE13_M_widen_initEv
  Referenced from: gnome/cy_gnome/cy_basic_types.so
  Expected in: /usr/lib/libstdc++.6.dylib
 in gnome/cy_gnome/cy_basic_types.so

Anyone seen this?

I'm guessing it's a clang / gcc issue, but I can't see what conda pacakges might have broken that.

distutils seems to be calling gcc, which is:

$ gcc --version
gcc (GCC) 4.8.5

and of course, a lot of g++:

$ g++ --version
g++ (GCC) 4.8.5

I've enclosed the conda package listing, but I can't see what would have messed this up.

-CHB

--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris....@noaa.gov

[Chris Barker]

On Fri, Nov 4, 2016 at 2:40 PM, Chris Barker <chris....@noaa.gov> wrote:

here's the error:

    import cy_basic_types # make sure it's imported, for the C++ lib

ImportError: dlopen(gnome/cy_gnome/cy_basic_types.so, 2): Symbol not found: __ZNKSt5ctypeIcE13_M_widen_initEv
  Referenced from: gnome/cy_gnome/cy_basic_types.so
  Expected in: /usr/lib/libstdc++.6.dylib
 in gnome/cy_gnome/cy_basic_types.so

BTW, cy_basic_types is a cython extension module -- I did think maybe this resulted in a newer Cython, but no -- downgrading Cython did not help :-(

-CHB

[Chris Barker]

On Fri, Nov 4, 2016 at 2:45 PM, Filipe Pires Alvarenga Fernandes <oce...@gmail.com> wrote:

Chris, if I got this correctly you want o build with gcc, but conda-forge uses clang (not my decision, I voted for gcc and lost).

hmm -- it's not me that wants to use gcc -- I think it's the default for distutils with the this version of python...

What I just found is that the environment that does works has a copy of libstdc++

whereas the one that doesn't work does not have that.

In both cases, the *.so is linked like so:

@rpath/./libstdc++.6.dylib (compatibility version 7.0.0, current version 7.19.0)

so in the case that works, it seems to be finding and using one provided by conda somehow, and the one that doesn't work is finding the system one.

if a do grep, both have that symbol -- which is wierd, and:

orrw-m-4179497:lib chris.barker$ otool -L /usr/lib/libstdc++.6.dylib

/usr/lib/libstdc++.6.dylib:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 104.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
/usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 125.0.0)

orrw-m-4179497:lib chris.barker$ otool -L libstdc++.6.dylib

libstdc++.6.dylib:
@rpath/./libstdc++.6.dylib (compatibility version 7.0.0, current version 7.19.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
@rpath/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

so they are both the same "compatibility version", but quite different "current versions".

If I put a copy of libstdc++ into the "broken" environment by hand, then it works!

So now I need to figure out how I got that lib in the other environment...

Is there any way to do a reverse lookup in conda? find out what package a file came from?

-CHB

 

So you need to use libc++. Something like [1] may help you.

Good luck!

[1] https://github.com/ocefpaf/libdap4-feedstock/blob/master/recipe/build.sh#L3-L9

[Chris Barker]

On Fri, Nov 4, 2016 at 3:09 PM, Chris Barker <chris....@noaa.gov> wrote:

If I put a copy of libstdc++ into the "broken" environment by hand, then it works!

the other question here is -- if I bulid in the environment without libstdc++ in it -- why doesn't it buld against the system lib, which is then linking with, and work???

it seems it's building against a different version of the lib than it's linking against at run time. odd

-CHB

[Chris Barker]

OK, sorry for having the whole conversation out loud -- but it helps me think :-)

And I think I've figured out what's going on!

I looked in the environment that works, and, indeed, it has the gcc package in it -- I put it there for fortran, but it installs libstdc++, and of course also gcc itself, and that's the one that is getting called for the build - so that all makes sense.

It turns out that I also have gcc installed in the root environment, so THAT's the one getting used in the "broken" environment. It uses the conda-supplied gcc to build, but does not have the conda-supplied libs.

Now I'm not sure if that's a bug or not -- it kinda seems like it is. If the root environment puts a compiler on the PATH, it should maybe put it's libs in DYLDLIBRARYPATH (or whatever it's called).

But that's a conda issue -- not a conda-forge one.

And now I know how I can fix it.

(thanks for listening :-) )

-CHB