Обсуждение: [HACKERS] ICU support on Windows
Hi All, Currently, we cannot perform ICU enabled build for postgres on Windows platform. However, this can be done on Linux platforms using '--with-icu' configuration parameter. Attached is the patch that allows us to perform icu enabled build for postgres on Windows platform provided that we have correct version of ICU libraries installed on our system. With the help of attached patch, we can use icu feature on Windows. All we have to do is, download the ICU libraries from - [1] and add the installation path for icu libraires in config.pl like, icu => 'E:\Users\pg\icu', [1]- http://site.icu-project.org/download/53 -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
On Sat, Jun 10, 2017 at 6:40 PM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote: > Currently, we cannot perform ICU enabled build for postgres on Windows > platform. However, this can be done on Linux platforms using > '--with-icu' configuration parameter. Attached is the patch that > allows us to perform icu enabled build for postgres on Windows > platform provided that we have correct version of ICU libraries > installed on our system. > > With the help of attached patch, we can use icu feature on Windows. > All we have to do is, download the ICU libraries from - [1] and add > the installation path for icu libraires in config.pl like, I have looked at this patch and it looks good to me. Windows is able to compile with ICU support using it, which is a good step forward into moving on with things in this area. I have added an open item, it seems to me that it is a mistake to not be able to have that support as well on Windows in PG10. -- Michael
Hi, On Mon, Jun 12, 2017 at 12:18 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Sat, Jun 10, 2017 at 6:40 PM, Ashutosh Sharma <ashu.coek88@gmail.com> wrote: >> Currently, we cannot perform ICU enabled build for postgres on Windows >> platform. However, this can be done on Linux platforms using >> '--with-icu' configuration parameter. Attached is the patch that >> allows us to perform icu enabled build for postgres on Windows >> platform provided that we have correct version of ICU libraries >> installed on our system. >> >> With the help of attached patch, we can use icu feature on Windows. >> All we have to do is, download the ICU libraries from - [1] and add >> the installation path for icu libraires in config.pl like, > > I have looked at this patch and it looks good to me. Windows is able > to compile with ICU support using it, which is a good step forward > into moving on with things in this area. > > I have added an open item, it seems to me that it is a mistake to not > be able to have that support as well on Windows in PG10. Thanks for reviewing the patch and adding it to the PostgreSQL 10 open items list. -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com
On 6/10/17 05:40, Ashutosh Sharma wrote: > With the help of attached patch, we can use icu feature on Windows. > All we have to do is, download the ICU libraries from - [1] and add > the installation path for icu libraires in config.pl like, > > icu => 'E:\Users\pg\icu', > > [1]- http://site.icu-project.org/download/53 Committed that. I noticed that this only works if you use the "Win32" download of ICU, because the "Win64" download uses "lib64" paths. I'm not sure what the impact of this is in practice. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, On Mon, Jun 12, 2017 at 8:39 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 6/10/17 05:40, Ashutosh Sharma wrote: >> With the help of attached patch, we can use icu feature on Windows. >> All we have to do is, download the ICU libraries from - [1] and add >> the installation path for icu libraires in config.pl like, >> >> icu => 'E:\Users\pg\icu', >> >> [1]- http://site.icu-project.org/download/53 > > Committed that. Thanks for that. > > I noticed that this only works if you use the "Win32" download of ICU, > because the "Win64" download uses "lib64" paths. I'm not sure what the > impact of this is in practice. Yes, that's right, Win64 download uses lib64 path and in my case i had renamed lib64-> lib and bin64-> bin which i guess is not a right thing to do. I think, we should allow Solution.pm to detect the platform and make a decision on the library path accordingly. Attached patch does that. Please have a look let me know your thoughts on this. Thanks. -- With Regards, Ashutosh Sharma EnterpriseDB:http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
Ashutosh Sharma wrote: > > I noticed that this only works if you use the "Win32" download of ICU, > > because the "Win64" download uses "lib64" paths. I'm not sure what the > > impact of this is in practice. > > Yes, that's right, Win64 download uses lib64 path and in my case i had > renamed lib64-> lib and bin64-> bin which i guess is not a right thing > to do. I think, we should allow Solution.pm to detect the platform and > make a decision on the library path accordingly. Attached patch does > that. Please have a look let me know your thoughts on this. Thanks. Uh, that's pretty odd. Is it something libicu-specific? Because I don't see any other occurrence of \lib64\ anywhere in the MSVC build scripts. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
On Jun 12, 2017 11:43 PM, "Alvaro Herrera" <alvherre@2ndquadrant.com> wrote:
Ashutosh Sharma wrote:Uh, that's pretty odd. Is it something libicu-specific? Because I
> > I noticed that this only works if you use the "Win32" download of ICU,
> > because the "Win64" download uses "lib64" paths. I'm not sure what the
> > impact of this is in practice.
>
> Yes, that's right, Win64 download uses lib64 path and in my case i had
> renamed lib64-> lib and bin64-> bin which i guess is not a right thing
> to do. I think, we should allow Solution.pm to detect the platform and
> make a decision on the library path accordingly. Attached patch does
> that. Please have a look let me know your thoughts on this. Thanks.
don't see any other occurrence of \lib64\ anywhere in the MSVC build
scripts.
Yes, it is specific to libicu.
On Tue, Jun 13, 2017 at 3:13 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Ashutosh Sharma wrote: >> > I noticed that this only works if you use the "Win32" download of ICU, >> > because the "Win64" download uses "lib64" paths. I'm not sure what the >> > impact of this is in practice. >> >> Yes, that's right, Win64 download uses lib64 path and in my case i had >> renamed lib64-> lib and bin64-> bin which i guess is not a right thing >> to do. I think, we should allow Solution.pm to detect the platform and >> make a decision on the library path accordingly. Attached patch does >> that. Please have a look let me know your thoughts on this. Thanks. > > Uh, that's pretty odd. Is it something libicu-specific? Because I > don't see any other occurrence of \lib64\ anywhere in the MSVC build > scripts. I do some low level packaging on Windows (libxml2, libxslt, etc.), and the compilation code usually allows you to usually use the installation paths you want. At the end using only lib/ looks more generic to me, and I did the same renaming as Ashutosh after unzipping their files. There is already "Program Files" and "Program Files (x86)" to make such distinctions. -- Michael
Michael Paquier wrote: > On Tue, Jun 13, 2017 at 3:13 AM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > Ashutosh Sharma wrote: > >> Yes, that's right, Win64 download uses lib64 path and in my case i had > >> renamed lib64-> lib and bin64-> bin which i guess is not a right thing > >> to do. I think, we should allow Solution.pm to detect the platform and > >> make a decision on the library path accordingly. Attached patch does > >> that. Please have a look let me know your thoughts on this. Thanks. > > > > Uh, that's pretty odd. Is it something libicu-specific? Because I > > don't see any other occurrence of \lib64\ anywhere in the MSVC build > > scripts. > > I do some low level packaging on Windows (libxml2, libxslt, etc.), and > the compilation code usually allows you to usually use the > installation paths you want. At the end using only lib/ looks more > generic to me, and I did the same renaming as Ashutosh after unzipping > their files. There is already "Program Files" and "Program Files > (x86)" to make such distinctions. Oh my. And then they say Microsoft has the brightest minds in the planet ... (apparently they're all at Facebook nowadays actually. Go figure.) Is this a problem on the packaging machine only, or does it cause fall-out on the machine in which the program runs? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Jun 13, 2017 at 6:47 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Michael Paquier wrote: >> I do some low level packaging on Windows (libxml2, libxslt, etc.), and >> the compilation code usually allows you to usually use the >> installation paths you want. At the end using only lib/ looks more >> generic to me, and I did the same renaming as Ashutosh after unzipping >> their files. There is already "Program Files" and "Program Files >> (x86)" to make such distinctions. > > Oh my. And then they say Microsoft has the brightest minds in the > planet ... (apparently they're all at Facebook nowadays actually. Go > figure.) :) > Is this a problem on the packaging machine only, or does it cause > fall-out on the machine in which the program runs? From Windows point of view, it depends on if you use /MD or /MT with cl.exe: https://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.110).aspx /MD makes binaries dynamically link to DLLs, making binaries sensitive to system updates. While /MT makes a binary bigger as the library becomes embedded into it. It is possible to see what an exe needs at runtime by using dumpbin /imports which lists all the dependencies needed by the binaries. And one can notice which option is used with cl.exe: - If msvcrXXX.dll is listed (XXX is the MSVC version), then /MD was used. - If msvcrXXXd.dll is listed, then /MDd was used. - If nothing is listed, then /MT was used. IMO, the places where the dll are placed is the problem of the packager, and Postgres uses /MD so if dll are misplaced there will be a run-time error because dependencies cannot be loaded. -- Michael
On 6/12/17 14:03, Ashutosh Sharma wrote: >> I noticed that this only works if you use the "Win32" download of ICU, >> because the "Win64" download uses "lib64" paths. I'm not sure what the >> impact of this is in practice. > > Yes, that's right, Win64 download uses lib64 path and in my case i had > renamed lib64-> lib and bin64-> bin which i guess is not a right thing > to do. I think, we should allow Solution.pm to detect the platform and > make a decision on the library path accordingly. Attached patch does > that. Please have a look let me know your thoughts on this. Thanks. committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 13 June 2017 at 05:47, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Michael Paquier wrote: >> On Tue, Jun 13, 2017 at 3:13 AM, Alvaro Herrera >> <alvherre@2ndquadrant.com> wrote: >> > Ashutosh Sharma wrote: > >> >> Yes, that's right, Win64 download uses lib64 path and in my case i had >> >> renamed lib64-> lib and bin64-> bin which i guess is not a right thing >> >> to do. I think, we should allow Solution.pm to detect the platform and >> >> make a decision on the library path accordingly. Attached patch does >> >> that. Please have a look let me know your thoughts on this. Thanks. >> > >> > Uh, that's pretty odd. Is it something libicu-specific? Because I >> > don't see any other occurrence of \lib64\ anywhere in the MSVC build >> > scripts. >> >> I do some low level packaging on Windows (libxml2, libxslt, etc.), and >> the compilation code usually allows you to usually use the >> installation paths you want. At the end using only lib/ looks more >> generic to me, and I did the same renaming as Ashutosh after unzipping >> their files. There is already "Program Files" and "Program Files >> (x86)" to make such distinctions. > > Oh my. And then they say Microsoft has the brightest minds in the > planet ... (apparently they're all at Facebook nowadays actually. Go > figure.) Personally I think that Program Files (x86) was added to punish people who fail to handle paths with spaces properly and finally make sure that everything got fixed. Because apparently "Program Files" wasn't annoying enough already. Ha, as if. People hard-code PROGRA~1 (the DOS shortname). And their scripts explode if there are no shortnames assigned or Program Files (x86) isn't PROGRA~1, it's PROGRA~2 or something else. You can't use %ProgramFiles(x86)% outside cmd.exe scripts. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Jun 13, 2017 at 6:45 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 6/12/17 14:03, Ashutosh Sharma wrote: >>> I noticed that this only works if you use the "Win32" download of ICU, >>> because the "Win64" download uses "lib64" paths. I'm not sure what the >>> impact of this is in practice. >> >> Yes, that's right, Win64 download uses lib64 path and in my case i had >> renamed lib64-> lib and bin64-> bin which i guess is not a right thing >> to do. I think, we should allow Solution.pm to detect the platform and >> make a decision on the library path accordingly. Attached patch does >> that. Please have a look let me know your thoughts on this. Thanks. > > committed Thank you :) > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services