<div class="gmail_quote">On Wed, Sep 28, 2011 at 8:52 PM, Michael Hertling <span dir="ltr"><<a href="mailto:mhertling@online.de">mhertling@online.de</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
</div>What do you do on systems which have no idea of symbolic links, e.g.<br>
previous Windows versions? Adding more platform-specific code to the<br>
sources of the FIND_LIBRARY() function? </blockquote><div><br>If the problem isn't solved (or readily solvable) on some platforms, we can just fall back to doing what we do now in those cases... we don't have to solve the problem on all possible platforms to improve the results on platforms that can be supported. The point wouldn't be to *guarantee* the result of find_library is a valid working library (it doesn't do that now), just improve the results by doing what can be done to avoid returning results that can be tagged as non-working (since a build trying to use such results is guaranteed to fail anyway.) Does cmake know (or can it tell) when it is cross compiling? If so, it could decide how much to test and not test in those cases.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Furthermore, the kernels of<br>
*nix systems hardly distinguish between binary files and text files;<br>
usually, they know just "files" with the limited exception of being<br>
able to recognize the native executable formats and the #! shebang.<br>
The detection of the diverse file types is typically implemented<br>
in utility programs, notably the file(1) utility.<br></blockquote><div><br>A linker test when possible (non-cross-compilation scenarios) with a fallback testing option using file introspection would handle a lot of situations, if I'm understanding correctly how this works. To the best of my knowledge and that of one of our other devs (he knows a lot more than me) there aren't any platforms where actual library files
(as opposed to linker scripts) consist solely of character values <128. Checking a found file for at least one character over 128 would avoid at least a few failure cases - empty files, plain text files, and dead links. Such a check would be reliable,
consist, and would be useful in eliminating files we might find
that are not actually library files.<br><br>Such a test of course wouldn't pass linker scripts like ubuntu's libc.so, but such a script *would* pass the actual linker test and would never get to file introspection. Actually if the script failed the linker test, then there is a real problem that should be a failure case. This would also be helpful in spotting early on the hypothetical case of a linker being tested that doesn't understand the .so linker script.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
>> But how do you test whether a library is "linkable"?<br></div></blockquote><div><br>If not cross-compiling, wouldn't it be possible to have find_library try the link as part of its test? Even in the case where linking isn't viable, falling back on the check on file contents would still be helpful. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">What do you do if the library found by FIND_LIBRARY() has a non-native<br>
binary format, e.g. for cross-compiling purposes? How do you select the<br>
right set of tools to check the library in question without the user's<br>
ado? IMO, FIND_LIBRARY()'s job is to find library files, and a general<br>
check whether these files are valid/usable/linkable and not dangling<br>
symlinks or whatever is beyond the scope of this function; ensuring<br>
that is rather the realm of system administration.<br></blockquote></div><br>I guess the question revolves around the expectation of find_library being different from find_file - as a user, my expectation would be that find_library is doing something to distinguish libraries from files (when that's technically workable, of course - clearly solving that problem in general is hard.) If something tricky like cross-compiling is going on then the simpler testing behavior is in order, but couldn't CMake scrub the results looking for library validity as much as possible? <br>
<br>Cheers,<br>CY<br>