On Mon, Jan 27, 2014 at 2:08 AM, Volker Schroer <address@hidden> wrote:
Hi Michael,
just for clarification:
My CMAKE_INSTALL_PREFIX points to a non existing directory at build and test
time. The libraries used depend on the LD_LIBRARY_PATH settings that point
to an existing installation.
In my case, I can avoid the problems by unsetting the LD_LIBRARY_PATH. It
seems that in such a case the libs in the build directory are found. But I
suppose that this could not be a general solution as in some cases other
important libraries like boost may be found be means of the LD_LIBRARY_PATH.
I agree that my patch is not a general solution for this problem, but only a
starting point.
A general solution could be to prepend the required test libraries to the
LD_LIBRARY_PATH as I did it in my patch for the volk lib.
-- Volker
Hey Volker,
When submitting patches, it's best to:
a) separate the patches to identify the specific purpose. In your
case, there's a patch to fix your QWT problem and another for the VOLK
library tests.
b) It's also best to submit this either on our issue tracker or as a
pull request on github; otherwise, it's likely that this will be
forgotten before the issue is fully resolved or missed entirely.
Thanks,
Tom
Am 26.01.2014 23:15, schrieb Michael Dickens:
On Jan 26, 2014, at 11:23 AM, Volker Schroer <address@hidden> wrote:
In brief: Depending on the settings make test does not always test what
should test.
Hi Volker - If GNU Radio is already installed into the PREFIX provided to
cmake during configuration, then during "make test" some of the
already-installed libraries will be found and used instead of those just
build. This condition can lead to some interesting "make test" errors!
I can say with confidence that the -built- libraries are all OK (I've
checked both the CMakeLists.txt files as well as used ldd or otool to see
what linkage is actually there; it's all good), it's just those found for
-testing- which can get mixed up.
This is a known problem for a while now (to me), and in my queue to work
on sooner or later. I believe that the issue is more extensive than just
adding VOLK to the library dependency list for each component. I encounter
this in MacPorts because, generally, the GNU Radio port is already installed
when an update comes along. The nice part is that it's trivial to replicate
in MacPorts, and thus easy to see what needs to be fixed; and, the "how"
part isn't too difficult either, just takes perseverance and time.
Thanks for the information and patch! - MLD
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio