Обсуждение: BUG #16336: Undefined symbols since upgrade of VS to 2019.5.2, and other issues
BUG #16336: Undefined symbols since upgrade of VS to 2019.5.2, and other issues
От
PG Bug reporting form
Дата:
The following bug has been logged on the website: Bug reference: 16336 Logged by: Mario Emmenlauer Email address: mario@emmenlauer.de PostgreSQL version: 12.2 Operating system: Windows 10 with Visual Studio 2019.5.2 Description: I've recently upgraded Visual Studio from 2019.3 to 2019.5.2. This broke my build of PostgreSQL. First I tried 11.5 which fails with the same errors, and now version 12.2 (from which I report this issue). First, in order to build with VS2019.5.2, I needed to make a small change to `src/tools/msvc/gendef.pl` because dumpbin fails for me when using backward slashes. So after the line my $tmpfile = "$ARGV[0]/tmp.sym"; I added: $tmpfile =~ s@\\@/@g; The build then continues, but later fails with 0 Warning(s), 2922 Error(s). The errors are due to undefined symbols. I did not change my build from VS2019.3, and I can also not reproduce the issue in VS2017, so it must be related to the upgrade of Visual Studio. I include a few of the undefined symbols here, but not the full list, for brevity: ``` Creating library Debug/plpgsql/plpgsql.lib and object Debug/plpgsql/plpgsql.exp pl_comp.obj : error LNK2019: unresolved external symbol pg_snprintf referenced in function do_compile [C:\gitlabci\postgres\plpgsql.vcxproj] pl_gram.obj : error LNK2001: unresolved external symbol pg_snprintf [C:\gitlabci\postgres\plpgsql.vcxproj] pl_scanner.obj : error LNK2001: unresolved external symbol errstart [C:\gitlabci\postgres\plpgsql.vcxproj] pl_comp.obj : error LNK2001: unresolved external symbol errstart [C:\gitlabci\postgres\plpgsql.vcxproj] pl_exec.obj : error LNK2001: unresolved external symbol errstart [C:\gitlabci\postgres\plpgsql.vcxproj] pl_gram.obj : error LNK2001: unresolved external symbol errstart [C:\gitlabci\postgres\plpgsql.vcxproj] pl_handler.obj : error LNK2001: unresolved external symbol errstart [C:\gitlabci\postgres\plpgsql.vcxproj] pl_scanner.obj : error LNK2001: unresolved external symbol errfinish [C:\gitlabci\postgres\plpgsql.vcxproj] pl_comp.obj : error LNK2001: unresolved external symbol errfinish [C:\gitlabci\postgres\plpgsql.vcxproj] pl_exec.obj : error LNK2001: unresolved external symbol errfinish [C:\gitlabci\postgres\plpgsql.vcxproj] pl_gram.obj : error LNK2001: unresolved external symbol errfinish [C:\gitlabci\postgres\plpgsql.vcxproj] pl_handler.obj : error LNK2001: unresolved external symbol errfinish [C:\gitlabci\postgres\plpgsql.vcxproj] pl_scanner.obj : error LNK2001: unresolved external symbol errcode [C:\gitlabci\postgres\plpgsql.vcxproj] pl_comp.obj : error LNK2001: unresolved external symbol errcode [C:\gitlabci\postgres\plpgsql.vcxproj] pl_exec.obj : error LNK2001: unresolved external symbol errcode [C:\gitlabci\postgres\plpgsql.vcxproj] [...] ```
Re: BUG #16336: Undefined symbols since upgrade of VS to 2019.5.2,and other issues
От
Mario Emmenlauer
Дата:
On 02.04.20 11:58, PG Bug reporting form wrote: > The following bug has been logged on the website: > I've recently upgraded Visual Studio from 2019.3 to 2019.5.2. This broke > my > build of PostgreSQL. First I tried 11.5 which fails with the same errors, Sorry for this, but it seems that PostgreSQL is not (directly) at fault for this problem. I can now isolate that within some of the Perl methods of the build, the PATH gets reset to the default Windows PATH. This seems to be related to the recent update of Visual Studio. Now this in turn triggers some unfortunate events: - I ensure that a native Perl is in PATH before any other Perl - I furthermore set the native Perl path in buildenv.pl - I start the build from the native Perl - But this PATH is reset to the default system PATH somewhere in the build - In the default system PATH, there is Cygwin Perl, which I require for building a few other packages Any help would be appreciated. Does someone know where/how the PATH may be reset in the build? Or are there any efforts to support Cygwin Perl for the build? I'm under the impression that most native tools support forward slashes as well as backward slashes. So maybe it would be possible to have support for Cygwin Perl *and* native Perl? But I may be misguided here, any help or feedback is appreciated! All the best, Mario Emmenlauer
Re: BUG #16336: Undefined symbols since upgrade of VS to 2019.5.2,and other issues
От
Mario Emmenlauer
Дата:
On 02.04.20 13:59, Mario Emmenlauer wrote: > > On 02.04.20 11:58, PG Bug reporting form wrote: >> The following bug has been logged on the website: >> I've recently upgraded Visual Studio from 2019.3 to 2019.5.2. This broke >> my >> build of PostgreSQL. First I tried 11.5 which fails with the same errors, > > Sorry for this, but it seems that PostgreSQL is not (directly) at fault for > this problem. I can now isolate that within some of the Perl methods of the > build, the PATH gets reset to the default Windows PATH. This seems to be > related to the recent update of Visual Studio. > > Now this in turn triggers some unfortunate events: > - I ensure that a native Perl is in PATH before any other Perl > - I furthermore set the native Perl path in buildenv.pl > - I start the build from the native Perl > - But this PATH is reset to the default system PATH somewhere in the build > - In the default system PATH, there is Cygwin Perl, which I require for > building a few other packages So I've finally found the root cause of the problem. I'm reporting this here in the hope it may be useful to somebody else in the future. Since more recent versions of Visual Studio 2019 (somewhere between VS 2019.3 and VS2019.5.2) a behavior with respect to PATH was changed. Since VS2017, the script `vcvarsall.bat` preserves the PATH before adding Visual Studio directories in `__VSCMD_PREINIT_PATH`. However as far as I could see, it is not used later anywhere again. This has changed in recent Visual Studio, where __VSCMD_PREINIT_PATH is later appended to PATH again! It turns out in my environment I clean Cygwin from PATH before building PostgreSQL, but I did not clean __VSCMD_PREINIT_PATH. So via this route, Cygwin was re-added to PATH, leading to build problems. Please close this issue, and thanks for your consideration. All the best, Mario Emmenlauer