Re: Building Postgres with lz4 on Visual Studio - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: Building Postgres with lz4 on Visual Studio |
Date | |
Msg-id | 8996fcd5-25fa-3983-42b3-7f50336afc70@dunslane.net Whole thread Raw |
In response to | Re: Building Postgres with lz4 on Visual Studio (Andrew Dunstan <andrew@dunslane.net>) |
List | pgsql-hackers |
On 2022-04-29 Fr 08:50, Andrew Dunstan wrote: > On 2022-04-26 Tu 16:26, Robert Haas wrote: >> On Wed, Apr 13, 2022 at 10:22 AM Melih Mutlu <m.melihmutlu@gmail.com> wrote: >>> What I realized is that c:\lz4\lib\liblz4.lib actually does not exist. >>> The latest versions of lz4, downloaded from [2], do not contain \liblz4.lib anymore, as opposed to what's written here[3]. Also there isn't a lib folder too. >>> >>> After those changes on lz4 side, AFAIU there seems like this line adds library from wrong path in Solution.pm file [4]. >>>> $proj->AddIncludeDir($self->{options}->{lz4} . '\include'); >>>> $proj->AddLibrary($self->{options}->{lz4} . '\lib\liblz4.lib'); >>> Even if I spent some time on this problem and tried to fix some places, I'm not able to run a successful build yet. >>> This is also the case for zstd too. Enabling zstd gives the same error. >>> >>> Has anyone had this issue before? Is this something that anyone is aware of and somehow made it work? >>> I would appreciate any comment/suggestion etc. >> In Solution.pm we have this: >> >> if ($self->{options}->{lz4}) >> { >> $proj->AddIncludeDir($self->{options}->{lz4} . '\include'); >> $proj->AddLibrary($self->{options}->{lz4} . '\lib\liblz4.lib'); >> } >> if ($self->{options}->{zstd}) >> { >> $proj->AddIncludeDir($self->{options}->{zstd} . '\include'); >> $proj->AddLibrary($self->{options}->{zstd} . '\lib\libzstd.lib'); >> } >> >> I think what you're saying is that the relative pathnames here may not >> be correct, depending on which version of lz4/zstd you're using. The >> solution is probably to use perl's -e to test which files actually >> exists e.g. >> >> if ($self->{options}->{lz4}) >> { >> $proj->AddIncludeDir($self->{options}->{lz4} . '\include'); >> if (-e $proj->AddLibrary($self->{options}->{lz4} . >> '\someplace\somelz4.lib') >> { >> $proj->AddLibrary($self->{options}->{lz4} . >> '\someplace\somelz4.lib'); >> } >> else >> { >> $proj->AddLibrary($self->{options}->{lz4} . '\lib\liblz4.lib'); >> } >> $proj->AddLibrary($self->{options}->{lz4} . '\lib\liblz4.lib'); >> } >> >> The trick, at least as it seems to me, is figuring out exactly what >> the right set of conditions is, based on what kinds of different >> builds exist out there and where they put stuff. > > I agree that we should use perl's -e to test that the files actually > exists. But I don't think we should try to adjust to everything the zstd > and lz4 people put in their release files. They are just horribly > inconsistent. > > What I did was to install the packages using vcpkg[1] which is a > standard framework created by Microsoft for installing package > libraries. It does install the .lib files in a sane place > (installdir/lib), but it doesn't use the lib suffix. Also it names the > lib file for zlib differently. > > I got around those things by renaming the lib files, but that's a bit > ugly. So I came up with this (untested) patch. > > er this patch -- Andrew Dunstan EDB: https://www.enterprisedb.com
Attachment
pgsql-hackers by date: