[lzma] Locate correct release/debug libraries in static build by seanwarren · Pull Request #5625 · microsoft/vcpkg

seanwarren · 2019-03-11T02:04:12Z

Currently, FindLZMA always detects the debug library for LZMA

This PR fixes the LZMA libraries detected by FindLZMA to ensure the correct configuration is used.

Neumann-A · 2019-03-11T08:08:54Z

Could you try commit 0b5a576

seanwarren · 2019-03-11T09:24:29Z

Unfortunately that commit does not fully resolve the issue (I'm still getting debug/lib/liblzma.a linked in). Some kind of systematic resolution to this problem would be great though!

Neumann-A · 2019-03-11T09:47:32Z

what other dependencies do you have? Could be that one of those is linking it in if it wasn't also build with the fix.
If you are building a vcpkg project tell me the name and i'll try it when i get home. I already have something more sophisticated for #5543 which is not yet pushed (0b5a576 was just one part of it). (Still figuring out if I only need to look/fix variable <Packagename><someextension>_LIBRARIES and check if it contains optimized and/or debug -> If it doesn't -> fix it) .

Maybe for testing add
message(STATUS LIBLZMA_LIBRARIES:${LIBLZMA_LIBRARIES})
after your
_find_package(${ARGS})
and see if it is correctly set with the commit. If it is, your linking wrongly from some other package

seanwarren · 2019-03-11T09:55:32Z

OK I'll have a look tomorrow (Syndey time). I'm building a project outside of vcpkg which depends on a number of ports. However I rebuilt all ports depending on liblzma.

seanwarren · 2019-03-15T08:01:18Z

@Neumann-A , to me it looks like that commit won't fix the problem for multi-configuration (i.e. MSVC) builds, or am I missing something?

Neumann-A · 2019-03-16T00:26:58Z

probably #5621
If the configuration release and debug work correctly and RelWithDebInfo and MinSizeRel are not correct you have to define the mappings for those. Otherwise CMake defaults to the debug configuration.

seanwarren · 2019-03-16T02:17:39Z

At the moment lzma debug libraries are included for both release and debug which is pretty undesirable for a performance sensitive library

seanwarren · 2019-03-19T07:46:06Z

@Rastaban, please could you let me know what is failing with this PR?

vicroms · 2019-03-19T23:07:28Z

Regression Status

Processing x64-linux                      616 vs 617
     collada-dom                   **regression**                Fail vs Pass

Processing x64-osx                        606 vs 610
     opencv                        **regression**                Fail vs Pass
     podofo                        **regression**                Fail vs Pass
     shaderc                                                     Pass vs Fail
     vtk                           **regression**                Fail vs Pass
     vtk-dicom                                                   Skip vs Pass
     zxing-cpp                                                   Skip vs Pass

 Processing x64-windows                    885 vs 886
     vxl                           **regression**                Fail vs Pass

 Processing x86-windows                    865 vs 866
     vxl                           **regression**                Fail vs Pass

vxl failed due to openjpeg being installed previously during the CI build (this can be ignored for now) with the message:

CMake Error at ports/vxl/portfile.cmake:4 (message):
  Can't build VXL with non built-in OpenJpeg in current version.  Please
  remove OpenJpeg, and try install VXL again.

collada-dom: fails with multiple compiler errors (click for log)

@Rastaban can you please provide MacOS logs?
Also, is your PR to fix collada-dom related to this PR?

…rapper

seanwarren · 2019-03-20T00:50:41Z

Unfortunately I can't reproduce any of the osx build failures with a clean checkout on this branch, I've re-pushed in case something has changed since the last build 9 days ago

NancyLi1013 · 2019-03-22T06:28:27Z

Hi @seanwarren , please see the MacOS logs.
macos_x64-osx_log.txt

seanwarren · 2019-03-22T06:33:57Z

Thanks @NancyLi013, unfortunately the logs are not publicly accessible, please could you attach them directly or provide an accessible link

seanwarren · 2019-03-25T09:31:33Z

Hello, please could you post the detailed error logs for the failing ports? The linked file only lists which port has failed.

vicroms · 2019-03-26T20:46:02Z

@Rastaban please provide MacOS logs

Neumann-A · 2019-03-27T00:16:19Z

@seanwarren where do you see the wrong linkage of lzma? With #5543 and libxml2 as a test I see the correct libraries linked into for Release and Debug. See the config of libxml2:
config-x64-windows-static-out.log

seanwarren · 2019-03-27T01:21:26Z

@Neumann-A, I've just tested #5543 and this seems to resolve the issue, at least for liblzma (nice work!). I'm happy to close this issue and wait for the more general solution

Neumann-A · 2019-03-27T07:05:23Z

@seanwarren: Just checked #5543 for file changes and forgot that the necessary change (0b5a576) is already merged within master (was added in #5574). So you dont need to wait, just update ;).
(Right now #5543 just adds a debugging message to see/debug issues.)

cenit · 2019-04-07T21:35:09Z

for what concern my problems, unfortunately @Neumann-A solution didn't fix anything, while this PR was very promising. Any possibilities you will open it again? Otherwise I will submit something similar in my OpenCV4 PR to fix LibLZMA, because otherwise the built is broken for downstream projects (not something that CI would catch without proper tests) when OpenCV library is built with static linking

seanwarren · 2019-04-08T00:14:44Z

@cenit - I'm linking to OpenCV statically on windows and mac and seem to be linking the correct debug/release configurations for LibLZMA. Does the same problem occur for you with the current OpenCV 3 port?

cenit · 2019-04-08T04:22:59Z

I just rebuilt opencv from scratch with the latest master.
What I find in OpenCVModules.cmake in share/OpenCV is the following snippet:

${_VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET}/debug/lib/lzma.lib;

which is even worse than what I was expecting and described in #5169 (comment)

and still wrong because OpenCV knows only about debug lib, while it should have the correct

\$<\$<NOT:\$<CONFIG:DEBUG>>:path/to/release/lib>;\$<\$<CONFIG:DEBUG>:path/to/debug/lib>;

I am saying "worse" because I fear (not tested, just finished building) that it is not even working now from the latest master, since the VCPKG_* symbols should stay out of the installed ports...

Since it looks like you did #5857 , can you confirm me that it is working? Is it even legit? Sorry for asking but this looked really new for me.

seanwarren · 2019-04-08T04:36:31Z

Since it looks like you did #5857 , can you confirm me that it is working? Is it even legit? Sorry for asking but this looked really new for me.

This is a workaround to replace absolute paths which prevent the port being exported by vcpkg. It works correctly as the VCPKG_* symbols are available when the package is located using find_package. On reflection, this could be replaced by a relative path since we always know where the OpenCVModules.cmake file is relative to the libraries.

seanwarren · 2019-04-08T04:39:11Z

Looking again at my vcpkg root, I think I failed to reinstall lzma before checking whether this is working. @cenit is correct and this problem still exists so I'm going to reopen this PR.

Neumann-A · 2019-04-08T05:43:44Z

looks like opencv #5857 is missing a vcpkg_fixup_cmake_targets (would also explain why the wrong library is linked because the script merges/splits release and debug targets; else only one is installed and which one depends on internal build/install order)
-> portbug in opencv

(in general the opencv portfile needs a lot of cleanup itself)

cenit · 2019-04-08T06:20:46Z

@Neumann-A unfortunately vcpkg_fixup_cmake_targets(), while being great, cannot do magic.
Even with an explicit call at the end for it, the lzma does not get fixed (just tried, again, in case something changed). There's no way it can understand that in one script there's a debug target and in the other a release one, since they are not flagged like that.
btw: there's an OpenCV4 PR open, which will be merged soon I hope. It will be cleaner than the current one, but it is taking time. Also, it requires this PR to be fully working (or an update from CMake upstream to their own FindLibLZMA.cmake script)

Neumann-A · 2019-04-08T07:08:21Z

@cenit I am just saying that the problem does not lie within the lzma port nor the find_package(LZMA) call. #5625 (comment) shows that the find_package call works as intended. The problem is the opencv portfile and simply adding vcpkg_fixup_cmake_targets to the end of it is of course not going to fix. The opencv portfile needs reworking starting somewhere after the vcpkg_install_cmake command. The vcpkg_wrapper added in this pr is just a drop of water on the hot stone not solving the real underlying problem.
If you want to find the real problem you probably want to look in the opencv buildtree and compare the generated target files for debug and release builds. The packanameconfig.cmake packanameconfigVersion.cmake and packanametargets.cmake typically get overwritten by what vcpkg does (had the same problem with hdf5 although I cannot find the link right now).
This is in general problematic if cmake does not generate the same packanametargets.cmake for release und debug builds.
(vcpkg should probably check if generated cmake files have the same content before trying to overwrite anything)
Let me add this one to #5543 but I currently don't have time to work on it because I am working on (https://bugs.llvm.org/show_bug.cgi?id=40701)

TL;DR:

Find out why opencv thinks lzma is somewhere else by looking at the opencv cmake/buildtree files (and nowhere else)

Neumann-A · 2019-04-08T07:15:59Z

@seanwarren If you want to fix it use a general fix of what you are doing in the vcpkg_cmake_wrapper.cmake for lzma and add it for all possible packages to vcpkg.cmake. See TODOs in #5543. Im happy to add PRs/changes to #5543. (need to filter the list of defined package variables a bit further to only _LIBRARIES and _LIBRARY (excluding _RELEASE and _DEBUG) and add more logic if something must be changed)

cenit · 2019-04-08T08:08:37Z

@Neumann-A it seems you missed the point.
The problem here fundamentally lies in the FindLibLZMA.cmake, which has never been updated for target handling and for the magnificient select_library_configurations() CMake function (not here, in the CMake project!). And I am telling it to you from the CMake point of view. This is a work that I (myself, again) opened there a long ago, but since I finished my time for the project it just stood there, for LZMA and for other libraries, which are typically not built via CMake. I will resume it maybe, whenever I will find some time. Or better, since we distribute the CMakeLists.txt for LZMA, I will just enhance to export the Config self-produced.

Your config log does not prove any point. It is the same for OpenCV. What you are showing was already happening, even well before your PR. The debug config finds only the debug library, the release config finds only the release library.
Unfortunately both are going to fill up the same symbol, LZMA_LIBRARIES, which does not handle configurations because of the issue above. So what you have in the end are two symbols filled differently and complementary and vcpkg_fixup_cmake_targets() is no help. If the LZMA_LIBRARIES was properly filled, just keeping the config-debug variant would have been ok, like it is for all other libraries in the project, because they would have been configuration enlightened.
I hope that now the problem is cleared.

Neumann-A · 2019-04-08T09:20:36Z

@cenit so your are basically telling me that the todo in #5543 (comment)

decide if _LIBRARY|LIBRARIES should always contain keywords debug and optimized even if not required to build (could solve the problem of debug/release targets being overwritten)

should be answered with a clear yes and both paths should be there.

My question is a bit different:
a) is this really required?
b) if yes - why?

so I went ahead and installed opencv.......

First I don't see any dependency on lzma please also mentions features in the future (i assume TIFF for now)
So I used this CMakeLists.txt for testing. What i see in VS is that LIBLZMA_LIBRARIES is not set correctly for multi generator project files. So this answers a) with "yes" and b) with "due to multi configuration generators" which decides the quote above. So to me the fix is quite clear and a general fix should be applied because more packages are probably affected.

@cenit: Next time please add a full problem description with all circumstances.

Only multi configuration generators of external projects are affected.
Everything in vcpkg itself links the correct libraries because vcpkg explicitly builds only one configuration at a time. The same is true for external projects which only build one configuration.
In multi configuration mode the configuration is not explicitly set and vcpkg defaults to add the debug path first. -> find_package will find only debug libraries for older libraries (because cmake will not search further or does not know how to find the difference in debug/release libraries -> because the internal CMake find is not updated to a newer CMake syntax).

Solution: update vcpkg.cmake to check packname_LIBRARY|LIBRARIES for existence of optimized & debug and add them + paths if it does not contain those keywords.

cenit · 2019-04-08T10:16:09Z

@Neumann-A please moderate your tones, this problem is old and well known and it's not like i have to rewrite a long post every time for every new user appearing: again, you are misunderstanding the problem without proper investigation.

Re-read the conversation, please, in full details.

Anyway, I appreciate your reply in full length, so here it is another advice: try a static build for a downstream project. It will fail, with or without multi-configuration generators, for debug or release depending on the patchset you are trying, because at link time the compiler will always be instructed to link to a specific version of lzma, not one dynamically selected if release or debug, since only one is known from the OpenCVModules.cmake. Only dynamic linking are without any problem, since external referencies to second order dependencies disappear. If you try a static one, you will recognize a mismatch between release and debug crt due to LZMA.

The proper way to deal with it is in CMake itself or through wrappers like the one proposed in this PR. Any other attempt to generalize a problem is just a big new coat of painting on a damaged wall, not just a dirty one, requiring too much effort for little gain. I will submit a PR for LZMA to fix it at the source.

seanwarren · 2019-04-08T11:30:04Z

I should also add that this issue is not restricted to opencv; the following CMakeLists.txt will fail to link the correct libraries for the release build when linked statically.

project (test)
find_package(LibLZMA REQUIRED)
add_executable(test test.cpp)
target_link_libraries(hello ${LIBLZMA_LIBRARIES})

I am concerned that any more general solution to this problem would risk significant off-target effects. I am not sure that the following statement is always true

decide if _LIBRARY|LIBRARIES should always contain keywords debug and optimized even if not required to build (could solve the problem of debug/release targets being overwritten)

To give one example, some ports (e.g. libiconv) link to the system library on mac/linux builds and in this case linking to a single library is probably the right thing to do. I think fixing this problem on a per-port basis (eventually upstream) is probably the safer way to go.

seanwarren · 2019-04-08T11:30:57Z

@Rastaban, @vicroms - please could you let me know which ports are failing

Neumann-A · 2019-04-08T11:53:25Z

@cenit: (The important conclusion of the comment is in bold.)

you are misunderstanding the problem without proper investigation.

OK, you want to have a fight of arguments lets go :) Building opencv:x64-windows-static (sry for the wrong triplet before).
So lets have a look at the buildtree as mentioned in #5625 (comment)

From the debug build (using debug path liblzma):

set_target_properties(opencv_imgcodecs PROPERTIES
  INTERFACE_LINK_LIBRARIES "opencv_core;opencv_imgproc;\$<LINK_ONLY:opengl32>;\$<LINK_ONLY:glu32>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/zlib.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/zlibd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/jpeg.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/jpegd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/libpng16.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/libpng16d.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/zlib.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/zlibd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/tiff.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/tiffd.lib>;

G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/lzma.lib

;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/jpeg.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/jpegd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/zlib.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/zlibd.lib>"
)

From the release build (using release path liblzma):

set_target_properties(opencv_imgcodecs PROPERTIES
  INTERFACE_LINK_LIBRARIES "opencv_core;opencv_imgproc;\$<LINK_ONLY:opengl32>;\$<LINK_ONLY:glu32>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/zlib.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/zlibd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/jpeg.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/jpegd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/libpng16.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/libpng16d.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/zlib.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/zlibd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/tiff.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/tiffd.lib>;

G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/lzma.lib

;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/jpeg.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/jpegd.lib>;\$<\$<NOT:\$<CONFIG:DEBUG>>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/lib/zlib.lib>;\$<\$<CONFIG:DEBUG>:G:/vcpkg_test/vcpkg/installed/x64-windows-static/debug/lib/zlibd.lib>"
)

(inserted line breaks to make the difference more obvious)

so OpenCVModules.cmake is different between release and debug builds. vcpkg installs only on of those or overwrites one by installing the other (does not really matter what exactly is happening either cmake tries to install the release version and sees it is already there or the debug install overwrites the release version [or somebody is messing around in the portfile (see end of comment)])....
That is something I already told you to check.... apparently you did not.

It is not the find_package call which is to blame, it works as intended within its constrains (although I really would like to see it working as you want it to but I don't know how it should work if the name of the library is the same for debug and release build. It would require an extra keyword like DEBUG|RELEASE_LIBRARY_SEARCHPATH or similar).

There are different ways to fix the issue:

fix find_package to emit the optimized;debug keywords with the correct path which will generate the correct generator expression in the target file.
Add the optimized;debug keywords with paths to the package defined variables which need it (that is [WIP][vcpkg] vcpkg can link wrong libraries (issue #5540 b) #5543)
let vcpkg_fixup_cmake_targets do the correction. Search for naked ;${_IMPORT_PREFIX}[^;] after INTERFACE_LINK_LIBRARIES and replace it with a generator expression. (Would require the correct regex)
Inserting the correct expression by hand into the target file which is probably the right fix in this case (see: below).

If you want to blame someone. Blame the person who put this line into the portfile (So it is not CMakes failure of find_package)
file(RENAME ${CURRENT_PACKAGES_DIR}/debug/share/opencv/OpenCVModules.cmake ${CURRENT_PACKAGES_DIR}/share/opencv/OpenCVModules.cmake)
so in this case it is a portbug in opencv.....please fix it.
(maybe we need a vcpkg_merge_targets scripts? maybe vcpkg_compare_release_debug_scripts within vcpkg_install_cmake which issues a warning if those are not equal.)

p.s.: Not just lzma has this problem. There are others packages which have the same problem, so a more general solution within vcpkg would be nice.

Neumann-A · 2019-04-08T11:58:15Z

I am concerned that any more general solution to this problem would risk significant off-target effects. I am not sure that the following statement is always true

decide if _LIBRARY|LIBRARIES should always contain keywords debug and optimized even if not required to build (could solve the problem of debug/release targets being overwritten)

To give one example, some ports (e.g. libiconv) link to the system library on mac/linux builds and in this case linking to a single library is probably the right thing to do. I think fixing this problem on a per-port basis (eventually upstream) is probably the safer way to go.

I think that problem is easily solved by checking the variable before changing it. So only variables which contain the vcpkg directory would be changed.

cenit · 2019-04-08T12:08:53Z

@Neumann-A Since I wrote those lines, I think I know that problem and I am the one to blame 😉.

The problem is well documented, in many appropriate places, and also here on vcpkg #5169 (comment)

No need to insert line breaks but thanks for the explanation.

And like @seanwarren is trying to tell you, it's not just an opencv problem. It's very simple to reproduce and it's an old cmake problem, which is very severe for any serious project trying to use LibLZMA in a world in which not just the release library is built. And like you also say, it's not just for LZMA.
If you just happened to be here, or even somewhere in the windows library world few years ago, you'd remember that the same problem existed for almost all of the libraries. Just for OpenCV it took me a lot of time for me to fix almost all. Just a patient work, upstream or with specific patch for every package manager and each single problem, gave us the situation in which we are here, which is much better I think.
Your contribution is useful, I really dream of a quick and easy solution to all these problems. What I fear is just that, since we never found one really working everywhere but we always had to rely on specific patch, that we just have to continue this patient work of fix each port and each script, here or upstream (better), waiting for a world in which every library is built officially through CMake (but I don't like no-choice...).

Neumann-A · 2019-04-08T12:27:46Z

@cenit Ok what i really don't understand is why you then did not include a simple

STRING(REPLACE "${_IMPORT_PREFIX}/lib/lzma.lib" "${_IMPORT_PREFIX}\$<\$<CONFIG:DEBUG>:/debug>/lib/lzma.lib" outvar ${invar})

to fix the OpenCVModules.cmake.

(the find_package issue in multi generator mode is a different issue)

Fleischner · 2019-04-08T16:47:12Z

just a curious question. (I'm not a cmake expert)

Cmakes find_package / find_library is required if cmake is used outside of an "controlled" environment. This is not the case with vcpgk. Normally build should be easy ;). There are at maximum n lib files from previous compilations that need to be found.

Wouldn't it be useful if cmake offers an plugin interface for controlled build environments, that replaces the default find_package find_library?
In this case find_package(port) will forward directly to the controlled build environment (here vcpkg) and vcpkg will just return all library files for this port and the current build configuration.

This would have a couple of advantages:

It would automatically solve all problems that wrong libraries from another configuration could be found, even if those have same names.
vcpkg can only allow to find packages from certain ports, thus checking that dependencies in the control file are correct
Manual and error prone corrections of find_package files are not longer necessary

seanwarren · 2019-04-08T20:44:10Z

@Fleischner - vcpkg does in fact intercept calls to find_package and modifies the results on a per-port basis (thats what the vcpkg-cmake-wrapper files do. Completely replacing the config/find** files for every port would be a very significant undertaking as these files do quite a bit more than just declaring the location of the library and all this work would have to be duplicated.

seanwarren · 2019-04-08T22:19:21Z

@Neumann-A , if you can come up with a general solution to this problem that would be great. However unfortunately I'm not able to devote time to that at the moment so will continue to work on this PR which solves the problem for liblzma

Neumann-A · 2019-04-09T06:32:39Z

@seanwarren Try #5543. I pushed changes yesterday which should take care of the problems. Currently running vcpkg ci x64-windows-static to discover possible regressions. Also included is a (incomplete) list of packages (#5543 (comment)) which are possible linked wrongly in indirect dependencies if the target of the direct dependency was not corrected in regards to DEBUG/RELEASE builds.

vicroms · 2019-04-10T20:41:29Z

Looks like this PR will be superseded by #6000 or used in combination with it.
But, in case you're still interested here are the latest CI results:

x64-windows	master	test	notes
vxl	Pass	Fail	Regression due to OpenJPEG being already installed, make a whitespace change to trigger a rebuild.

x64-windows-static	master	test	notes
vxl	Pass	Fail	Regression

x64-osx	master	test	notes
opencv	Pass	Fail	Regression
zxing-cpp	Pass	Skip

x86-windows	master	test	notes
vxl	Pass	Fail	Regression

arm-uwp	master	test	notes
tmx	Pass	Fail	Regression

seanwarren · 2019-04-12T07:02:05Z

Thanks @vicroms.

@cenit - are you happy with the approach of #6000? If so I won't chase down these last few regressions.

…-static-targets

seanwarren · 2019-05-22T07:09:56Z

@vicroms - please could you let me know what has failed here? Thanks

cenit · 2019-05-30T22:01:30Z

@seanwarren has #6000 fixed your problems (now merged into master)? I sincerely hope so...

vicroms · 2019-09-09T17:50:42Z

This issue should have already been fixed on master
@seanwarren can you confirm this?

seanwarren · 2019-09-09T18:31:58Z

Yes this can now be closed

Neumann-A mentioned this pull request Mar 11, 2019

[assimp] fix linux build #5632

Merged

cenit mentioned this pull request Mar 16, 2019

[OpenCV] Update to v4.1.1 #5169

Merged

[lzma] Locate correct release/debug libraries in static build using w…

72c7b56

…rapper

seanwarren force-pushed the fix-lzma-static-targets branch from c76d69d to 72c7b56 Compare March 20, 2019 00:45

seanwarren closed this Mar 27, 2019

seanwarren deleted the fix-lzma-static-targets branch March 29, 2019 00:04

seanwarren restored the fix-lzma-static-targets branch April 8, 2019 04:36

seanwarren reopened this Apr 8, 2019

Neumann-A mentioned this pull request Apr 8, 2019

[WIP][vcpkg] vcpkg can link wrong libraries (issue #5540 b) #5543

Closed

cenit mentioned this pull request Apr 8, 2019

[LibLZMA] automatic configuration #6000

Merged

Merge branch 'vcpkg-master' into fix-lzma-static-targets

89be696

Merge commit 'e16f9c29a05aa178ce8a476a293723ab92f08f89' into fix-lzma…

aaaf9b7

…-static-targets

Merge remote-tracking branch 'origin/master' into HEAD

de0d196

cbezault assigned vicroms Aug 27, 2019

seanwarren closed this Sep 9, 2019

Conversation

seanwarren commented Mar 11, 2019

Uh oh!

Neumann-A commented Mar 11, 2019

Uh oh!

seanwarren commented Mar 11, 2019

Uh oh!

Neumann-A commented Mar 11, 2019

Uh oh!

seanwarren commented Mar 11, 2019

Uh oh!

seanwarren commented Mar 15, 2019

Uh oh!

Neumann-A commented Mar 16, 2019

Uh oh!

seanwarren commented Mar 16, 2019

Uh oh!

seanwarren commented Mar 19, 2019

Uh oh!

vicroms commented Mar 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Regression Status

Uh oh!

seanwarren commented Mar 20, 2019

Uh oh!

NancyLi1013 commented Mar 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seanwarren commented Mar 22, 2019

Uh oh!

seanwarren commented Mar 25, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vicroms commented Mar 26, 2019

Uh oh!

Neumann-A commented Mar 27, 2019

Uh oh!

seanwarren commented Mar 27, 2019

Uh oh!

Neumann-A commented Mar 27, 2019

Uh oh!

cenit commented Apr 7, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seanwarren commented Apr 8, 2019

Uh oh!

cenit commented Apr 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seanwarren commented Apr 8, 2019

Uh oh!

seanwarren commented Apr 8, 2019

Uh oh!

Neumann-A commented Apr 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cenit commented Apr 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Neumann-A commented Apr 8, 2019

Uh oh!

Neumann-A commented Apr 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cenit commented Apr 8, 2019

Uh oh!

Neumann-A commented Apr 8, 2019

Uh oh!

cenit commented Apr 8, 2019

Uh oh!

seanwarren commented Apr 8, 2019

Uh oh!

seanwarren commented Apr 8, 2019

Uh oh!

Neumann-A commented Apr 8, 2019

Uh oh!

Neumann-A commented Apr 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cenit commented Apr 8, 2019

vicroms commented Mar 19, 2019 •

edited

Loading

NancyLi1013 commented Mar 22, 2019 •

edited

Loading

seanwarren commented Mar 25, 2019 •

edited

Loading

cenit commented Apr 7, 2019 •

edited

Loading

cenit commented Apr 8, 2019 •

edited

Loading

Neumann-A commented Apr 8, 2019 •

edited

Loading

cenit commented Apr 8, 2019 •

edited

Loading

Neumann-A commented Apr 8, 2019 •

edited

Loading

Neumann-A commented Apr 8, 2019 •

edited

Loading

vicroms commented Apr 10, 2019 •

edited

Loading