Michael Fischer wrote:
> Hi Dick,
>
> the LIB problem is a general LIB problem, because the
> libusb and libftdi will not be found.
>
> Your line look like:
>
> set(CONDITIONAL_LIBS ${LIBFTDI_LIBRARIES} ${CONDITIONAL_LIBS})
>
> I know that my libs was installed here:
>
> /opt/local/libftdi-0.15
>
> Therefore I changed you like for testing:
>
> set(CONDITIONAL_LIBS "/opt/local/libftdi-0.15/lib/libftdi.a"
> ${CONDITIONAL_LIBS})
>
> And now I have no link problems with libftdi. I have done it the
> same for libusb, but got now some errors that following symbols
> can not be found:
>
> IODestroyPlugInInterface,
> CFRunLoopStop
> IOMasterPort
>
> and more. All this symbols was referenced in darwin.c
>
> First of all, I think there is a problem with the find_package.
>
find_package() I believe is C++ code within CMake. We call it from
src/CmakeModules/*.cmake.
The two http:// links I sent you fully describe the "problem" and why it
has not been fixed. The second http:// link clearly shows that Windows
is holding back a solution.
But the first link shows another way on how to solve your problem on a
UNIX like platform, that is, to have the *.a file override the *.so file.
As to your most recent problem:
When the libusb.so file is linked, it would have the same potential for
the problem you are seeing. I would suggest that you look into how
libusb.so is being linked on your platform, and include whatever library
is being added to that link, also into your link, statically or
dynamically.
If it is elf format, libusb.so may tell you what it needed during link
time, perhaps with tools readelf or nm. Or you can download the source
to libusb and find out what it needs.
I don't remember readelf or nm off the top of my head.
If you copy the command output from make, you can paste it onto your
command line and experiment interactively with the up arrow until you
get it right, then work backwards into the CMake script.
Realize that your current problem is not one with CMake but with libusb,
and that mailing list is now a better source of information.
Dick
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
