On 09/29/2011 02:52 AM, Michael Hertling wrote: > On 09/29/2011 01:30 AM, Clifford Yapp wrote: >> On Wed, Sep 28, 2011 at 2:47 AM, Michael Wild <them...@gmail.com> wrote: >> >>> >>> Only if your installation is broken ;-) If the symlink is broken, I >>> consider this to be a user-error. Period. OTOH, CMake /could/ check >>> whether the library is a symlink, and if it is, check that it is valid. >>> >> >> Oh, no question the installation is broken. I'd just expect find_library to >> do whatever minimal validation it can easily do and not return invalid cases >> it can spot - checking for symlink and whether it's valid would catch one >> general class of error, and perhaps a quick check to see if the file is a >> binary or a text file would be another. Not perfect, but such tests should >> be relatively simple and would improve the utility of find_library. > > What do you do on systems which have no idea of symbolic links, e.g. > previous Windows versions? Adding more platform-specific code to the > sources of the FIND_LIBRARY() function? Furthermore, the kernels of > *nix systems hardly distinguish between binary files and text files; > usually, they know just "files" with the limited exception of being > able to recognize the native executable formats and the #! shebang. > The detection of the diverse file types is typically implemented > in utility programs, notably the file(1) utility.
And to add to the confusion, GNU ld also accepts linker scripts which are text files, but are named like libraries. E.g. on my Ubuntu 11.04 box /usr/lib/x86_64-linux-gnu/libc.so is actually a linker script. file(1) uses "magic" numbers and heuristics to detect the file type, and it certainly isn't bulletproof... Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
