On Oct 10, 2012, at 10:31 AM, Curtis Olson wrote:
Hopefully one of our cmake gurus can jump in and comment at this point. I get
clean builds on Fedora, so if I ran into something like this on my system, I'd
probably wipe my build try and start from scratch.
yep, building clean
I may look at
Hi Rich,
I tried your little test on my own fedora system and it worked fine, no
link error.
I don't know if this is helpful, but you could try running "nm -D
/usr/lib64/libudev.so". I see the following along with everything else:
003dc6203370 T udev_new
Sounds like you are already on top
Resending as first was rejected for being too long, sigh. Am I on the right
mailing list? Is this a developer topic?
On Oct 10, 2012, at 10:31 AM, Curtis Olson wrote:
Hopefully one of our cmake gurus can jump in and comment at this point. I get
clean builds on Fedora, so if I ran into someth
Hopefully one of our cmake gurus can jump in and comment at this point. I
get clean builds on Fedora, so if I ran into something like this on my
system, I'd probably wipe my build try and start from scratch. I may look
at making sure simgear was built at the same time and from the same vintage
an
Hi, we do have libudev-devel installed...
rcook@rzgpu52 (flightgear-2.8.0-build): rpm -qf /lib64/libudev.so.0
libudev-147-2.40.el6.x86_64
rcook@rzgpu52 (flightgear-2.8.0-build): ls /usr/include/libudev.h
/usr/include/libudev.h
rcook@rzgpu52 (flightgear-2.8.0-build): rpm -qf !$
rpm -qf /usr/include
Hi Rich,
One quick thing to try to would be to make sure you have the -devel version
of the library installed. That usually provides .h / include files and
also static versions of the libs. I don't know how this is specifically
checked for in cmake, but often you look for the correct .h file (or
