On Tue, Jun 13, 2017 at 6:47 AM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
