BUG #16773: GSSAPI + Msys2/mingw64 + setenv() issue.

Started by PG Bug reporting formover 5 years ago4 messagesbugs
Jump to latest
#1PG Bug reporting form
noreply@postgresql.org

The following bug has been logged on the website:

Bug reference: 16773
Logged by: George Tarasov
Email address: jatoba@gaz-is.ru
PostgreSQL version: 12.0
Operating system: Windows MSYS2/MINGW64
Description:

Dear hackers,

I am being engaged in PostgreSQL build process with GSSAPI support in
msys2/mingw64 environment.
Everything is good enough on REL_11_STABLE branch, but there are the
following compilation and linking errors on newer versions/branches
(12-stable, 13-stable, and 14-devel).

Errors connect with setenv() call that isn't supported in msys2/mingw64.

be-secure-gssapi.c: In function 'secure_open_gssapi':
be-secure-gssapi.c:493:3: warning: implicit declaration of function
'setenv'; did you mean 'getenv'? [-Wimplicit-function-declaration]
setenv("KRB5_KTNAME", pg_krb_server_keyfile, 1);
^~~~~~
getenv

libpq/be-secure-gssapi.o: In function `secure_open_gssapi':
D:\postgresql\src\backend\libpq/be-secure-gssapi.c:493: undefined reference
to `setenv'
collect2.exe: error: ld returned 1 exit status

I have read this [1]/messages/by-id/30119.1576538578@sss.pgh.pa.us, this [2]/messages/by-id/29478.1576537771@sss.pgh.pa.us, and this [3]/messages/by-id/CAEudQArtoobDWsYV300qPrg4Nms_v6DkiBiewZ9nzn+KQKd9Qw@mail.gmail.com and as i understood it's
recommended to use more convenient putenv() insted of setenv().
But the function setenv() is still there and the patch proposed in [3]/messages/by-id/CAEudQArtoobDWsYV300qPrg4Nms_v6DkiBiewZ9nzn+KQKd9Qw@mail.gmail.com have
not yet been approved.

Please comment
Is there a plan to clean code from setenv() call and will the proposed patch
[3]: /messages/by-id/CAEudQArtoobDWsYV300qPrg4Nms_v6DkiBiewZ9nzn+KQKd9Qw@mail.gmail.com
Or setenv() is our Happy Future and PG-code will stay broken for non-common
execution environments, namely those, that use, for example, GSSAPI support
in msys2/mingw64.

Also I have checked BuildFarm statuses and all mingw64-nodes build PG
without GSSAPI/KRB5 support [4]https://buildfarm.postgresql.org/cgi-bin/show_status.pl.
It looks like the mingw64 platform is no longer being considered as LTS and
will be in reduced feature list in the future.
Am i right?

Thanks!

[1]: /messages/by-id/30119.1576538578@sss.pgh.pa.us
[2]: /messages/by-id/29478.1576537771@sss.pgh.pa.us
[3]: /messages/by-id/CAEudQArtoobDWsYV300qPrg4Nms_v6DkiBiewZ9nzn+KQKd9Qw@mail.gmail.com
/messages/by-id/CAEudQArtoobDWsYV300qPrg4Nms_v6DkiBiewZ9nzn+KQKd9Qw@mail.gmail.com
[4]: https://buildfarm.postgresql.org/cgi-bin/show_status.pl

#2Stephen Frost
sfrost@snowman.net
In reply to: PG Bug reporting form (#1)
Re: BUG #16773: GSSAPI + Msys2/mingw64 + setenv() issue.

Greetings,

* PG Bug reporting form (noreply@postgresql.org) wrote:

I am being engaged in PostgreSQL build process with GSSAPI support in
msys2/mingw64 environment.
Everything is good enough on REL_11_STABLE branch, but there are the
following compilation and linking errors on newer versions/branches
(12-stable, 13-stable, and 14-devel).

Errors connect with setenv() call that isn't supported in msys2/mingw64.

Yeah, we had some discussion regarding that, as you noted. There's been
a further discussion though, here:

/messages/by-id/CA+OCxowDNTXfHBruAryhZA0aMxHvqHL4uYk8APiZCqjWAM=M-w@mail.gmail.com

Which seems to indicate that fixing the setenv() issue isn't enough to
make things actually work. I'd been hoping that Dave would get back to
that thread and provide some feedback on it, but that's not happened
yet.

Perhaps you could take his patch and see if it works for you though..?

Is there a plan to clean code from setenv() call and will the proposed patch
[3] or its revised versions be applied ??

Would really be helpful if we could have some confidence that such a
change would actually result in things working- so, if you could test
the patch that Dave posted in the thread I linked to above and let us
know if it works for you, that'd certainly be helpful.

Also I have checked BuildFarm statuses and all mingw64-nodes build PG
without GSSAPI/KRB5 support [4].
It looks like the mingw64 platform is no longer being considered as LTS and
will be in reduced feature list in the future.

I don't think there's any reason to jump to that assumption, however..

Am i right?

.. if you'd like this to keep working then I would certainly encourage
you to set up a buildfarm animal which tests this case and register it
with the buildfarm. The lack of one certainly means it's less likely
that this specific platform + configuration will be tested regularly.

Thanks,

Stephen

#3Michael Paquier
michael@paquier.xyz
In reply to: Stephen Frost (#2)
Re: BUG #16773: GSSAPI + Msys2/mingw64 + setenv() issue.

On Mon, Dec 14, 2020 at 02:38:36PM -0500, Stephen Frost wrote:

.. if you'd like this to keep working then I would certainly encourage
you to set up a buildfarm animal which tests this case and register it
with the buildfarm. The lack of one certainly means it's less likely
that this specific platform + configuration will be tested regularly.

+1.  Environments run with buildfarm animals get also immediate
attention from committers as we try to never keep things red for a too
long time.
--
Michael
In reply to: Stephen Frost (#2)
RE: BUG #16773: GSSAPI + Msys2/mingw64 + setenv() issue.

Stephen,

Yes, I will definitely try proposed patch.
It seems obvious and in a current PG-code-style. I mean it's the same as putenv()/unsetenv().
But there is some misunderstanding why it is needed to have two functions putenv() and setenv() doing slightly same things??
It's a question to oneself rather, not needed to discuss here.
Probably exist some memory issues as noted in neighebour GSSAPI threads and threads referenced above.

So.
I think I can reproduce build environment and test all variants (patch/putenv + mingw64/msvc), but it's a work not for the one day.
I am starting digging and also will track this thread and publish my results later.

Making buildfarm agent is not possible at the moment due to the testing status of this work.
But it may be possible to setup one in our infrastructure in the future if test results will be considered as acceptable.

Thank you for your reply!
Regards
George Tarasov

-----Original Message-----
From: Stephen Frost [mailto:sfrost@snowman.net]
Sent: Monday, December 14, 2020 10:39 PM
To: Jatoba <Jatoba@gaz-is.ru>; pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16773: GSSAPI + Msys2/mingw64 + setenv() issue.

Greetings,

* PG Bug reporting form (noreply@postgresql.org) wrote:

I am being engaged in PostgreSQL build process with GSSAPI support in
msys2/mingw64 environment.
Everything is good enough on REL_11_STABLE branch, but there are the
following compilation and linking errors on newer versions/branches
(12-stable, 13-stable, and 14-devel).

Errors connect with setenv() call that isn't supported in msys2/mingw64.

Yeah, we had some discussion regarding that, as you noted. There's been a further discussion though, here:

/messages/by-id/CA+OCxowDNTXfHBruAryhZA0aMxHvqHL4uYk8APiZCqjWAM=M-w@mail.gmail.com

Which seems to indicate that fixing the setenv() issue isn't enough to make things actually work. I'd been hoping that Dave would get back to that thread and provide some feedback on it, but that's not happened yet.

Perhaps you could take his patch and see if it works for you though..?

Is there a plan to clean code from setenv() call and will the proposed
patch [3] or its revised versions be applied ??

Would really be helpful if we could have some confidence that such a change would actually result in things working- so, if you could test the patch that Dave posted in the thread I linked to above and let us know if it works for you, that'd certainly be helpful.

Also I have checked BuildFarm statuses and all mingw64-nodes build PG
without GSSAPI/KRB5 support [4].
It looks like the mingw64 platform is no longer being considered as
LTS and will be in reduced feature list in the future.

I don't think there's any reason to jump to that assumption, however..

Am i right?

.. if you'd like this to keep working then I would certainly encourage you to set up a buildfarm animal which tests this case and register it with the buildfarm. The lack of one certainly means it's less likely that this specific platform + configuration will be tested regularly.

Thanks,

Stephen