Обсуждение: BUG #16336: Undefined symbols since upgrade of VS to 2019.5.2, and other issues

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]
[...]
```

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

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