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:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Building Postgres with lz4 on Visual Studio
Next
From: Andrew Dunstan
Date:
Subject: Re: SQL JSON compliance