<p>Am 21.11.2016 11:40 schrieb "Alfred" <<a href="mailto:alfred@consulab.nl">alfred@consulab.nl</a>>:<br>
><br>
> Well.<br>
><br>
> All files that are needed by the linker, have to be found by the linker.<br>
> The osxcrosstools use a findfile process that is a bit peculiar. And not fully understood by me. Perhaps you can help.<br>
><br>
> c++ code.<br>
><br>
> findFile(path):<br>
> Options::FileInfo Options::findFile(const std::string &path) const<br>
> calls:<br>
> if ( findFile(path, {".tbd"}, result) )<br>
> return result;<br>
><br>
> findFile(path,{...},result):<br>
> bool Options::findFile(const std::string &path, const std::vector<std::string> &tbdExtensions, FileInfo& result) const<br>
> calls<br>
> for ( const auto &ext : tbdExtensions ) {<br>
> auto newPath = replace_extension(path, ext);<br>
> bool found = tbdInfo.checkFileExists(*this, newPath.c_str());<br>
> }<br>
><br>
><br>
> So, as far as I understand correctly, if a fpc abc.o file is presented towards the linker, it replaces the extension with tbd and goes looking for abc.tbd.<br>
> I checked: if I add a dummy abc.tbd in the same location, all goes well.<br>
><br>
> That why I patched the search-process. But this very rude patch only took care of .o files.<br>
> I forgot about the .or files.<br>
><br>
> Trying new patches at the moment to no avail unfortunately.</p>
<p>IMHO they should first try to match the file as-is and only then use their own extension.<br>
So your patch of Options::findFile should first check the passed on file name path and if that's found fill the result information as is done when the loop sets result to true. Only if that fails it should loop.<br>
If that works you might want to present the patch to the developers.</p>
<p>Regards,<br>
Sven</p>