Field G. Van Zee

@JohnCC330 Hi John. Give 727edd8 a try. It conforms more closely to GNU standards for library naming, library installation, and installation prefix manipulation, and contains other goodies for convenience and...

@JohnCC330 This is a very typical error message on some operating systems. [Here](https://www.in-ulm.de/~mascheck/various/argmax/) is another good resource on the topic. Frustratingly, this issue does not manifest in every environment /...

@JohnCC330 For your curiosity, my Haswell workstation running Ubuntu 16.04 returns: ``` $ xargs --show-limits Your environment variables take up 3720 bytes POSIX upper limit on argument length (this system):...

Unfortunately SVD in libflame is not easy to debug because it uses a completely different algorithm than the one in LAPACK. So for now, I'll encourage you both to use...

@srvasanth I took a look at your netlib test logs, and I think you can safely ignore these as false failures. libflame uses a different Householder transformation than the one...

@rkingsbury Thanks for this report, and sorry for your troubles. Another user has [reported this issue](https://groups.google.com/g/libflame-discuss/c/tQXNQYd-EVE/m/gf0kdBgYDgAJ). I don't think the error has anything to do with it being AMD's packaging...

Not at this time, but that doesn't mean it won't happen. (Honestly, I haven't looked at `amd/libflame`, so I don't know how much there would be to merge or conflict-resolve.)

@sgsokol Yes, I agree that unused symbols should not be referenced. This issue probably went unnoticed for so long because very few people use a shared library builds of libflame....

@sgsokol Try out 5151689, which disables the code found in the `map/lapack2flamec/f2c/c/?la_*_extended.c` files. Hopefully that takes care of all of the unresolved symbols, but if there are more, we'll iterate...

@sgsokol Yes, of course--I disabled the code that *defines* the xblas functions but forgot to disable the code that *calls* those functions. I'll work on it. Basically, I have to...