A lot of C libraries on 64-bit Linux like to install libraries into $PREFIX/lib64 instead of $PREFIX/lib. A few try to cross compile 32-bit and 64-bit libraries by default and put 32-bit libraries in lib/ and 64-bit libraries in lib64/ (like gcc unless you use --without-multilib).
There's no point in cross compiling with conda, so lib64 is useless. Should we automatically symlink lib64 to lib/ in conda build, and remove the link when the build is done in 64-bit Linux? This would make it so you don't have to worry about it (I also noticed some Linux distros do this with /lib64 and /lib). Would this break anything? @ilanschnell
I have just encountered this issue. Cmake by default installs into lib64 on linux, which conda build does not include in library paths (at least it's not in the setuptools build_ext command).
This ship sailed a long, long time ago. There are literally thousands of recipes that depend on the current behavior. Sorry, but I don't think we're going to reintroduce lib64. Symlinking seems dangerous to me, as there are some things (notably gcc) that put things in lib64, and moving them is fragile.
If you disagree and you'd like to work on a better solution to this problem, PRs would be most welcome. It may be workable to create the symlink in the build and host envs if and only if the folder doesn't already exist.
I wasn't really suggesting to change anything about the situation, just that one can still encounter this thing when building their first conda package. With Cmake, it's as easy as -DCMAKE_INSTALL_LIBDIR=lib. I think this can be closed, but someone else can still find the information here useful in the future.
Most helpful comment
I wasn't really suggesting to change anything about the situation, just that one can still encounter this thing when building their first conda package. With Cmake, it's as easy as
-DCMAKE_INSTALL_LIBDIR=lib. I think this can be closed, but someone else can still find the information here useful in the future.