Beware vcpkg (archived discussion)

[m-7761]

Original title: 3 probs: libusb in InitialSetup_X bat; ServerLog.h prevent Cmake config. SDL2/libusb require manual building

Libusb spits out erros like the following via the InitialSetup scripts. The thirdparty\libusb\msvc\libusb_2015.sln project is not plagued by this. I don't understand what the problem is. It's like it thinks there is more than one definition file:

libusb-1.0.lib(core.obj) : error LNK2005: libusb_get_version already defined in libusb-1.0.lib(libusb-1.0.dll)

I think that just looks bad. FYI libusb has a strerror.c file that causes nightmares for people with multibyte locales. Maybe a wiki should mention it.

Unrelated: The CMake script appears to not locate thirdparty\SDL2. But really it just has to be built. I think -DHAVE_LIBC may have prevented it from building. I had to remove it due to 3 errors to get the current SDL2 code to build.

Lastly Cmake won't finish configuring because "src\psvrservice\Service\ServerLog.h" is missing it says. I added a blank file.

I don't know if https://github.com/HipsterSloth/PSVRTracker/wiki/Building-from-source has instructions for libusb and sdl because they are difficult or what, but it came in handy in my case.

Luckily Visual Studio seemed to download/setup OpenCV. Which was pretty cool. I didn't realize it was missing up to that stage. Some output lines suggest it used Vcpkg for that purpose:

3> VcpkgTripletSelection:
3> Using triplet "x64-windows" from "C:\vcpkg\installed\x64-windows\"

(OpenCV seems unnecessarily large. Maybe it's all necessary. I'm skeptical.)

I want to be of help. I hope I can be. Or at least, I hope I can get tracking working very well. And I hope I don't get in the way.

[m-7761]

We've discussed this some here (#14) including some solutions.

I just want to reiterate that I feel the goto failure pattern should be done away with file wide. I.e. completely. I think the only reason I had to build SDL manually is probably that it came after libusb in the script. Had it been able to build after libusb failed, it would've saved me a lot of trouble.

I also want to stress that I believe there's something seriously wrong with building libusb with this script on my system. I don't understand what it is though. (Example link error output is in the top-post details. I think using MSBuild that way is likely the problem. I have a feeling it's not equivalent to opening the SLN file and building it from within VS.)

[m-7761]

EDITED: Figured this out. See next reply.

----stale info-----------------------------

Just FYI, the InitialSetup script still fails to link libusb.

MSBuild.exe libusb_2017.sln /tv:15.0 /p:configuration=DEBUG /p:Platform="x64" /t:Clean;Build

Search for terms like cmd MSBuild "already defined in" LNK2005 turns only maybe this: https://stackoverflow.com/questions/28372396/msbuild-exe-is-not-respecting-linklibrarydependencies

I'm honestly surprised this works for you. I think maybe it fails because there isn't a build-dependency in the libusb projects... they have a DLL and static version. But usually the DLL has an express dependency on the static version. Maybe they can build separately. It's just a hunch. (Maybe if the static project could be targeted first it would take.)

After failing. I think the script tried to run GenerateProjectFiles_X64.bat. But it seems to have not worked. There is a build folder left in scripts/vc2017 that I can't understand how it got made...

Maybe it failed because CMake package scripts could not locate libraries for libusb, since it didn't build. I guess that's not so bad a design.

[m-7761]

GOOD NEWS.

I got stuck on the new OpenCV somehow. Trying to understand what it was doing... it was linking (somehow) against two different versions of OpenCV. One was 330d, and the other 320d.

Just barely I saw this in the output: /LIBPATH:"C:\vcpkg\installed\x64-windows\debug\lib"

Even though it's not in the projects listed directories, nor in its command-line. It's somehow injected by VS. I've also confirmed this is the libusb problem described here...

Basically, VS injects vcpkg. It somehow finds the library dependencies, even though they are not in the linker inputs. What's weird is it does this on the commandline, but not inside VS (opened to solution file.) Whereas with OpenCV it does happen inside VS.

Anyway, the problem is with vcpkg. But honestly, if it's picking up on vcpkg somehow, it would really be better if PSVRTracker were using the vcpkg system on Windows, and using packages on other systems too.

I installed these two packages via vcpkg in anticipation to link against them, only to find that I needed the other thirdparty externals, which also included these. Unfortunately, I did spend some time trying to get the CMake scripts to find the packages inside vcpkg without any success. It's broken going forward and backward... two different ways. The only fix seems to be to abandon vcpkg for the time being :(

vcpkg remove opencv libusb

EDITED: The only reason this didn't bite me before, is somehow the thirdparty libraries must have changed from 320 to 330. I think 320 happened to match the vcpkg file name.

[HipsterSloth]

Oh! That is super interesting. Well for what it's worth, Chad Boulay (the other maintainer of PSMoveService) is in the process of upgrading PSMoveService to vcpkg literally this week. This means I need to get vcpkg working on my machine anyway. So as part of this process I'll just switch over to using vcpkg for PSVRTracker as well. Which I guess will be nice because that would completely remove the need for the InitialSetup.bat script correct (since the packages are pre-compiled)?

…

On Mon, Mar 11, 2019 at 9:40 PM Mick Pearson ***@***.***> wrote: GOOD NEWS. I got stuck on the new OpenCV somehow. Trying to understand what it was doing... it was linking (somehow) against two different versions of OpenCV. One was 330d, and the other 320d. Just barely I saw this in the output: /LIBPATH:"C:\vcpkg\installed\x64-windows\debug\lib" Even though it's not in the projects listed directories, nor in its command-line. It's somehow injected by VS. I've also confirmed this is the libusb problem described here... Basically, VS injects vcpkg. It somehow finds the library dependencies, even though they are not in the linker inputs. What's weird is it does this on the commandline, but not inside VS (opened to solution file.) Whereas with OpenCV it does happen inside VS. Anyway, the problem is with vcpkg. But honestly, if it's picking up on vcpkg somehow, it would really be better if PSVRTracker were using the vcpkg system on Windows, and using packages on other systems too. I installed these two packages via vcpkg in anticipation to link against them, only to find that I needed the other thirdparty externals, which also included these. Unfortunately, I did spend some time trying to get the CMake scripts to find the packages inside vcpkg without any success. It's broken going forward and backward... two different ways. The only fix seems to be to abandon vcpkg for the time being :( E.g. 'vcpkg remove opencv libusb` — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQBA_UatRJQ_8E10dMktMEq0QgrGgQr6ks5vVy_BgaJpZM4baAD8> .

[m-7761]

The benefit of vcpkg is it is a shared source, like most open-source operating systems have. It's meant to emulate Linux package systems on Windows. VS has a "NuGet" system, but I've never used it, and I don't know if it was unpopular with devs or what. So they made Vcpkg. Or someone in Microsoft did. It's still kind of new. Only popular libraries are on it.

From this experiment it seems like you are stuck with whatever version you have installed... since VS couldn't seem to understand that the 320d builds were not what was appropriate to the link command-line. The problem is, I have yet to see it used with CMake. There are a lot of articles, but what they recommend seems to not work. So it may be hard to mix with CMake. I will look at your scripts after you do it, and try to replicate them for some of my own projects :)

[m-7761]

Note (see above reference to microsoft/vcpkg#4562) I took this to vcpkg. It's a near criminal design flaw/bug. I still don't understand how /LIBPATH:"C:\vcpkg\installed\x64-windows\debug\lib" is able to recruit *320d.lib when linking to *330d.lib. I think there must be more too it. Maybe there is a symlink like system in vckpg's lib folder.

[HipsterSloth]

Yeah that is pretty crazy. Isn't there a MSVC option for see more detailed output about how where it's pulling libraries from? Maybe I'm just thinking of the flag that generates the compiler intermediate files (header + cpp smoshed together).

In any event, thanks for writing up that detailed bug. Hopefully they can get that fixed soon. Sorry you had to do all that troubleshooting.

[m-7761]

There are two options (I kind of remembered one) in the Project's Linker settings. I tried it with a vanilla library and it spat out the same output 6 times. I'm not sure how to interpret it. I guess it prints libraries when it opens them to try to find definitions.

A second option says it prints progress when linking... that sounds like a good option, especially when linking takes minutes. Or more. You can see how slowly my brain works. I had to get a nights rest to realize I should look into the status of that bug in the Vcpkg issue tracker. It's like my brain only works when I'm sleeping. The rest of the time I'm a mindless automaton.

[m-7761]

Eureka! After a (second) night's rest, it occurred to me what's really happening here, is VS2015 doesn't have automatic vcpkg integration. VS2017 does. And running MSBuild.exe on the command-line must be using 2017 with the 2015 build C++ build chain.

That has to be why libusb failed on the command-line build. It occurred to me it's unlikely that the CMake script changed from 320d to 330d; that there is probably another explanation. The reason being, that OpenCV linked before because it wasn't using vcpkg.