Kornel Benko wrote: > Am Montag, 6. April 2015 um 02:22:24, schrieb Uwe Stöhr <uwesto...@web.de> >> Tex2lyx cannot be compiled and the problem is commit: >> >> http://www.lyx.org/trac/changeset/66fa801e74e1775b31008df548332436ce79e2e1/lyxgit >> >> by JMarc. Reverting this commit makes LyX compilable for me. >> >> The problem for the compiler seems to be the Length::inPixel feature. >> >> JMarc, could you please have a look? >> >> thanks and regards >> Uwe >> > > It should not be. According to your previous post, it is unresolved > from lyx::theFontMetrics(class lyx::FontInfo const &), but for tex2lyx it > is part of 'src/tex2lyx/dummy_impl.cpp'.
My experience with compiler or linker errors that look like they cannot happen is that the compiler or linker is usually correct, and that it usually tells the very problem in the error message, but for various reasons I do not understand the error message. Therefore, in situations like this I try to re-read the error message very carefully, maybe also changing a few bits of code to see what happens, and usually this reveals the real problem. Therefore it is so important that the raw errors are posted (which Uwe did), not only the interpretations. This approach works in this particular case as well. The error message reads: "D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj.metaproj" (Standardziel) (23) -> "D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj" (Standardziel) (24) -> (Link target) -> Length.obj : error LNK2019: Link to unresolved external symbol ""class lyx::frontend::FontMetrics const & __cdecl lyx::theFontMetrics(class lyx::FontInfo const &)" (?theFontMetrics@lyx@@YAABVFontMetrics@frontend@1@ABVFontInf o@1@@Z)" in Funktion ""public: int __thiscall lyx::Length::inPixels(class lyx::MetricsBase const &)const " (?inPixels@Length@lyx@@QBEHABVMetricsBase@2@@Z)". [ D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] D:\LyXGit\Master\compile-result\bin\Debug\tex2lyx.exe : fatal error LNK1120: 1 unresolved external link. [D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj] Let us analyze it: 1) The linker complains about an unresolved symbol. 2) The name of the symbol is lyx::frontend::FontMetrics. 3) Cannot be! This symbol is in dummy_funcs.cpp. 4) Maybe it is the order of the objects on the linker command line as Kornel suggested? No, this is not the case (you could either try it out, or remember that the linker commandline order usually not matter for object files, only for libraries in certain cases). 5) OK, there must still be an error in the reasoning above. Assuming that the linker is correct it can only be item 3) => read dummy_funcs.cpp again very carefully 6) Bingo! dummy_funcs.cpp contains a class lyx::FontMetrics, not lyx::frontend::FontMetrics Now the fix is easy. I implemented it (without testing since I don't have MSVC on this machine), but I am very sure that it works. The main issue with errors like this is that us humans do not read what is in the source code, but what is meant to be in the source code. Unfortunately the compiler is not that clever. When investigating such issues it does also help if you have experience with more than one toolchain. Therefore I did not think too long about the question why the linux linker worked for the same code: I simply assumed that it tries harder to remove unused code, and therefore simply does not need the missing symbol. BTST several times, also the other way round: In some cases the MSVC linker is more clever to remove unused stuff. Without this experience you might need much more time (trying to find out why linux works), but if you concentrate on the error message only and try to work your way from that it should still be possible to find the cause of the problem. Georg