Thread: BUG #18668: [Windows] September 2024 releases (17.0, 16.4, etc) all include older libiconv-2.dll

The following bug has been logged on the website:

Bug reference:      18668
Logged by:          James Scott
Email address:      james.scott@hpe.com
PostgreSQL version: 17.0
Operating system:   Windows
Description:

All of the September 2024 releases (17.0, 16.4, etc) all include
libiconv-2.dll version 1.15. This is a regression from the 1.17 version
which has been included since PostgreSQL 11 at least. 

This appears to be the case in both the -binaries.zip and the Windows
installer. 

Per the installer source at
https://github.com/EnterpriseDB/edb-installers/blob/REL-17/server/packages-win64.txt,
it appears that the intention is to continue bundling 1.17. 

Perhaps the transition in
https://github.com/EnterpriseDB/edb-installers/commit/8ec613dbfb52430101804244984e201e2cbfdbc0
created an opportunity for an older, cached version to be included? 

To be clear, PostgreSQL seems to work just fine with the older version of
the DLL. I noted it when updating an embedded version of the -binaries
package, and wanted to give your build environment folks a chance to find
the problem while it's benign. 

Thanks!


Hi James,

Thanks for the report.

Kritika, can you please look into this? 


On Mon, Oct 21, 2024 at 11:26 PM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      18668
Logged by:          James Scott
Email address:      james.scott@hpe.com
PostgreSQL version: 17.0
Operating system:   Windows
Description:       

All of the September 2024 releases (17.0, 16.4, etc) all include
libiconv-2.dll version 1.15. This is a regression from the 1.17 version
which has been included since PostgreSQL 11 at least.

This appears to be the case in both the -binaries.zip and the Windows
installer.

Per the installer source at
https://github.com/EnterpriseDB/edb-installers/blob/REL-17/server/packages-win64.txt,
it appears that the intention is to continue bundling 1.17.

Perhaps the transition in
https://github.com/EnterpriseDB/edb-installers/commit/8ec613dbfb52430101804244984e201e2cbfdbc0
created an opportunity for an older, cached version to be included?

To be clear, PostgreSQL seems to work just fine with the older version of
the DLL. I noted it when updating an embedded version of the -binaries
package, and wanted to give your build environment folks a chance to find
the problem while it's benign.

Thanks!



--
Sandeep Thakkar


Hi James,

This is not regression, in the past we have used iconv v1.15 as we are using gettext v0.19.8 and iconv v1.15 comes with it by default. 

Per the installer source at https://github.com/EnterpriseDB/edb-installers/blob/REL-17/server/packages-win64.txt, we will update the version here.

In the future we are planning to update the gettext version and also the iconv, but we are still looking into that issue.


On Fri, Oct 25, 2024 at 4:50 PM Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> wrote:
Hi James,

Thanks for the report.

Kritika, can you please look into this? 


On Mon, Oct 21, 2024 at 11:26 PM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      18668
Logged by:          James Scott
Email address:      james.scott@hpe.com
PostgreSQL version: 17.0
Operating system:   Windows
Description:       

All of the September 2024 releases (17.0, 16.4, etc) all include
libiconv-2.dll version 1.15. This is a regression from the 1.17 version
which has been included since PostgreSQL 11 at least.

This appears to be the case in both the -binaries.zip and the Windows
installer.

Per the installer source at
https://github.com/EnterpriseDB/edb-installers/blob/REL-17/server/packages-win64.txt,
it appears that the intention is to continue bundling 1.17.

Perhaps the transition in
https://github.com/EnterpriseDB/edb-installers/commit/8ec613dbfb52430101804244984e201e2cbfdbc0
created an opportunity for an older, cached version to be included?

To be clear, PostgreSQL seems to work just fine with the older version of
the DLL. I noted it when updating an embedded version of the -binaries
package, and wanted to give your build environment folks a chance to find
the problem while it's benign.

Thanks!



--
Sandeep Thakkar




--
Warm Regards,
Kritika Agarwal