make fails when lib and lib64 directories are both present

[ajpotts]

After this PR:
#3423

make fails if both lib and lib64 are present and the necessary dependencies are in lib.

@stress-tess @brandon-neth @bmcdonald3

[stress-tess]

yah so just to provide some extra context. @ajpotts was having linker issues after pulling down the latest master. I don't have the specific error on me, maybe amanda can post it. But I took a look at her --ldflags and it was passing conda_path/arkouda-dev/lib64, but mine was arkouda-dev/lib. we did an ls on the lib64 path and it was pretty barebones

We didn't know if this was the problem at the time, so we just wiped the env and rebuilt from yaml and that fixed things. We noticed afterwards that the ldflags now pointed to the arkouda-dev/lib directory

Given all that, it seems likely that this is due to #3424. As far as I understand, before that PR it would always add the lib path and add the lib64 path if that directory exists. But now if the lib64 dir exists, it only adds the lib64 path. I don't know why she had the lib64 dir when I don't but my best guess was a previous run of make install deps?

I'm not exactly sure what's the best way to go about addressing this since that PR was added to fix an issue @brandon-neth was running into. But I also don't love the idea that ppl might have their make start breaking with kinda hard to track down linker issues. Amanda suggested adding a warning if we could to give ppl an idea of what might be going on and I think that would be great if possible

[bmcdonald3]

I think I would be in favor of just going back to the old way, I'm not sure anyone else has ever encountered the error that led to #3423 when we were in that state for a couple of years, so it seems more likely to be an issue with the specific environment this was run in, rather than an issue with the build script itself... It seems unsatisfying, but I think it is hard to argue with years of never having encountering an issue and then a change causing issues very soon after, it is likely the change that is "less correct" if that makes sense.

[stress-tess]

I think I would be in favor of just going back to the old way, I'm not sure anyone else has ever encountered the error that led to #3423 when we were in that state for a couple of years, so it seems more likely to be an issue with the specific environment this was run in, rather than an issue with the build script itself... It seems unsatisfying, but I think it is hard to argue with years of never having encountering an issue and then a change causing issues very soon after, it is likely the change that is "less correct" if that makes sense.

yah that makes sense to me! I'm up for going back to the old logic

[ajpotts]

If you're curious, here is the error I was seeing:

                            init :   0.001 seconds
/usr/bin/ld: cannot find -lhdf5: No such file or directory
/usr/bin/ld: cannot find -lhdf5_hl: No such file or directory
/usr/bin/ld: cannot find -liconv: No such file or directory
/usr/bin/ld: cannot find -lparquet: No such file or directory
/usr/bin/ld: cannot find -lhdf5: No such file or directory
/usr/bin/ld: cannot find -lhdf5_hl: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
error: Make Binary - Linking