Context:
I am following the guide for the open source project OpenSC https://github.com/OpenSC/OpenSC to compile the solution on Windows and get the opensc-pkcs11.dll module to use it for communications (such as OpenSSH) with HSM's via PKCS#11 standard. Currently I am using the latest stable release 0.21.0 (msi installer) and it works perfectly. However when I use https://github.com/OpenSC/OpenSC/wiki/Compiling-on-Windows guide to compile the solution using Visual Studio Developer Command Prompt I can successfully build the libraries however the opensc-pkcs11.dll always returns pkcs11: 0x5: CKR_GENERAL_ERROR when I try to use it and I am not sure what am I missing here.
Setup:
git clone https://github.com/OpenSC/OpenSC.git
git checkout 30180986a08cf71fe4af4b50251a8bb5b1ab95af (0.21.0 commit for the right version)
Manually Creating Built Source Files
nmake /f Makefile.mak
Building it for x64, with x64 Native Tools Command Prompt for VS 2019.
That should be it according to the guidelines as I do not need openpace/openssl/zlib to compile the opensc-pkcs11 as far as I understand.
Problem summary:
If I download from releases https://github.com/OpenSC/OpenSC/releases version OpenSC-0.21.0 the compiled opensc-pkcs11.dll works as expected
If I compile it from source code based on v0.21.0 commit I get 0x5: CKR_GENERAL_ERROR when trying to use the library for e.g. OpenSSH, tested that this happens for other/previous commits as well, there for I suspect that I am missing something here.
Has anyone experienced the same issue? Maybe there is some build config anyone could share so I can understand what am I missing here?
Related
Is there a way or steps to follow to integrate a yocto SDK (standard or extensible) with VSCode? I want to cross-compile, remote connect, and debug a C/C++ application within VSCode for target hardware using a yocto generated Linux image. Is this possible? I know of the bitbake extension but couldn't find one for the SDK. Thank you!
Conservatively, I would say it depends on the level of integration you want to achieve but I use regularly VS Code to edit and build, sometime to debug C applications using a Yocto toolchain, that's really easy for Makefile projects for example.
Assuming you do not ask for Yocto integration into VS Code (I don't know if something exists) but really to use the tools generated by the SDK from Yocto and that you already are familiar with Yocto toolchain usage.
I personally compile on Linux server remotely from a Windows PC. The server contains therefore my projects and the Yocto toolchain.
I use for that the nice Remote SSH extension from Microsoft on VS Code. From there, I can edit easily the files, compile and a terminal is available (that's out of the scope of your question however).
So if working as me or directly in Linux, you can create a Makefile/CMake project for example. The C/C++ VS Code extension is a must have.
Each time you start working, you source the Yocto SDK toolchain and compile directly using make from the terminal window of VSCode. If you want to automatize the build step, you can use the task feature of VS which allows you to launch build script for example.
Regarding the remote connect, the terminal window of VS can also have multiple sub-windows with various connections like SSH to the target. The build script can also use scp to send the generated binary directly to the target but your question is vague regarding what you want to do.
Finally for the debug aspect, GDB is well supported in VS Code and the official doc is a good start as well as the C++ debugging doc.
On the Yocto side, you need to add gdbserver to the image running on the target, it can be done by adding the following to your conf/local.conf:
EXTRA_IMAGE_FEATURES += "tools-debug"
If you want to have debug information for the shared libs on the target, you also need to add:
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
Finally, the SDK must be generated with the same options as the image running on the target and will contain the cross-gdb tool like -gdb to be used on the host side.
So that's possible but requires some setup especially the debug part. As far as I know, there is not a VS Code extension managing all these steps for you automagically.
I have a Cmake/wxWidgets project that builds fine on my pc.
I compile wxWidgets using nmake /f makefile.vc BUILD=release TARGET_CPU=X86 and generate the CMake project using cmake .. -G "Visual Studio 16 2019" -A Win32 -DCMAKE_CONFIGURATION_TYPES=Release.
Like I wrote, this compiles fine on my pc. When I want to build it using a github action on Windows 2019 Image I first pull wxWidgets, compile it using the above statement, generate wxWidgets using the aboce statement and trigger the build using a cmd-script containing "%programfiles(x86)%\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" ".\build\NaCl-Configurator.sln" /p:Configuration=Release /p:Platform=Win32 /p:PlatformTarget=x86
But when doing this I always get the following error:
wxmsw31u_core.lib(corelib_wincmn.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86' [D:\a\abc\abc\build\abc.vcxproj]
If I switch everything to x64 it compiles fine, but I need a x86 build. Is there any system setting I'm missing?
This is not an answer, this is a recommendation.
But after spending hours looking into your issue, I am seriously pulling my hair at the Microsoft documentation for MSBuild.
Just use Ninja. This is what we use to build our x64/x86 binaries.
You might need to learn a little bit about cmake toolchains, but at least you don't have to deal with this msbuild nonsense.
Ninja is faster, works much better with cmake, is a very tiny executable, etc.
Seriously using msbuild/visual-studio on your servers isn't worth it.
Again I apologize this isn't a direct answer to your question, if you do continue down this path I'm curious to see the answer.
====================================================
What I found out though:
I will say I'm very confused about the difference between PlatformTarget and Platform. Because all the visual studio solutions I generate don't even have PlatformTarget as a property anywhere. I scanned the generated solution files and didn't see this anywhere. Granted I'm using vs2019 so maybe it's deprecated I dunno.
Prefer to expand the /p -> /property that's just good practice for your build server scripts.
Perhaps try using the platform property "x86" instead. I literally couldn't find concrete information on which was preferred/correct. Win32/x86.
And as a final guess please start printing out your compiler, and toolchain information from cmake.
Resources:
How do I specify the platform for MSBuild?
https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019
Me looking at the msbuild command line, and looking at my generated visual studio solutions.
I was using another github action to access nmake to build wxWidgets. Within this action I had to specify the architecture.
So using
- name: Preparing nmake
uses: ilammy/msvc-dev-cmd#v1
with:
arch: x86
- name: start building wx widgtes
run: |
cd ${{ env.WXWIN }}${{ env.wxMSW_VER }}\build\msw
nmake /f makefile.vc BUILD=release TARGET_CPU=X86
and then going on did the trick. It was only the with: arch: x86 that was missing
We're currently using the Resharper command-line tool 2016.3 on our CI build server to inspect code for issues at build time. It's working pretty well but I still have an issue and I can't find any proper documentation on that : how do I install and configure an extension using the command line. For example, I want to add the Cyclomatic complexity extension to my analysis. Documentation said to use the -x switch with the name of the extension (PowerToys.CyclomaticComplexity). The code inspection runs but the complexity warning aren't included in my result file, probably because the extension isn't installed on my build server which make sense. I don't have VS installed on my build machine (and I would prefer not to have to) so how can I install the extension "manually" ?
Thanks
The command line tools in 2016.3 don't currently fully support loading extensions. This comment in the issue tracker has some steps that might be able to support - basically put the .nupkg of the extension in the product folder. YMMV.
I´m trying to build paraview from source, therefore using:
Windows 7
Visual Studio 2010
Qt 4.8.7
Python 2.7.8
msmpi 7
paraview source, version 5.1.0
In CMake I can choose different options to specify what functionality to include into the build process. I tried different combinations, like setting BUILD_EXAMPLES or PARAVIEW_USE_MPI, respectively. Now I have got following questions:
When I set BUILD_SHARED_LIBS and PARAVIEW_ENABLE_PYTHON as well (besides others), configuring and generating the project with CMake is successful, but compiling in VS fails; it keeps freezing right after starting the compilation. Did anybody experience the same problem and how did you solve it? (By the way, if I unset BUILD_SHARED_LIBS it works, but I don´t want a static build of Paraview).
By using the combination BUILD_EXAMPLES, BUILD_TESTING, PARAVIEW_BUILD_QT_GUI, PARAVIEW_ENABLE_CATALYST, PARAVIEW_ENABLE_PYTHON and PARAVIEW_USE_MPI the same problem as described in 1.) occurs, but that is more or less what I need to use Catalyst to perform in-situ analysis of my FEM simulation. (Incidentally, if I unset BUILD_TESTING in the above combination it works, but I need CTest to test the Catalyst examples as described here. Does anybody now how to fix that problem?
As shown at GitHub, some examples have been updated to work properly in Paraview 4.4. Is my version of Paraview (5.1.0) unsuitable for the Catalyst examples? Is that the reason why VS is always hanging up for particular variable settings in CMake and which version of Paraview is most suitable to get the Catalyst examples going?
I'd appreciate any help!
That's odd! There's no known reason for this. Although I haven't used VS2010 explicitly, we do have dashboards testing with 2013 and I build with VS2015 with no issue.
I'd recommend using the Ninja as the builder rather than the IDE, however. Just run cmake-gui.exe from appropriate VS studio command prompt and pick Ninja as the build generator. Then, to build, just run ninja in the build directory.
We want to add command-line support to Netbeans, as in being able to run any program (using the full path of the current file as the argument) directly from the IDE. The same way you can do it already on Notepad++ with the Run tool.
Apparently there is a plugin called VCS Generic Command-Line Support that offers this functionality, but when we try to install it we get this error message:
Some plugins require Master Filesystem to be installed
The plugin Master Filesystem is
requested in version >= 1.1 but only
2.15.2 was found.
Any ideas?
EDIT
I Did some googling as you got me interested pretty much everything i found was in refernce to NetBeans 5.x or below... Im thinking maybe its not compatible with 6 - but thats just a guess.
Looks like a version incompatability with "Master Filesystem". Maybe they are checking the version improperly or perhaps they really mean it needs to be 1.x >= 1.1. Do you have the newest version of VCS Plugin?
As an aside if Im going to have to chek this out... ive been dying for external tool support like in my beloved Eclipse :-)