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 f5483fc8-cddb-befa-5421-5d3f4e01f985@dunslane.net
Whole thread Raw
In response to Re: Building Postgres with lz4 on Visual Studio  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Building Postgres with lz4 on Visual Studio  (Andrew Dunstan <andrew@dunslane.net>)
Re: Building Postgres with lz4 on Visual Studio  (Andrew Dunstan <andrew@dunslane.net>)
Re: Building Postgres with lz4 on Visual Studio  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.


cheers


andrew


[1] https://github.com/microsoft/vcpkg

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: pg_walcleaner - new tool to detect, archive and delete the unneeded wal files (was Re: pg_archivecleanup - add the ability to detect, archive and delete the unneeded wal files on the primary)
Next
From: Andrew Dunstan
Date:
Subject: Re: Building Postgres with lz4 on Visual Studio