Cannot Open Source File Stddef.h Visual Studio 2019
Austin Vermont
Most likely, you ended up updating some of the components (e.g. BSP or some libraries to versions that are not 100% backward-compatible, and then tried to troubleshoot it by changing some setting that ended up breaking the project.
Thanks, we have rechecked stddef.h on Advanced CMake, but it looked just fine. Could you please attach a screenshot of the entire Visual Studio window, showing the error and the Solution Explorer window as well?
One piece of good news is the junk characters I was seeing in my ARM Semihosting Console seems to have resolved itself. I cleaned up some recent code and the problem went away. I was probably overwriting an array or buffer somewhere that was stepping on the semihosting memory.
@GeneM, it is hard to say why you would end up with 2 copies of the same BSP. VisualGDB has a mechanism for relocating the BSPs, leaving links to the new location behind, so it could be that you somehow triggered that one. Either way, the best way to get a clean BSP would be to close VS, delete %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.stm32, and install the BSP again.
@bjornharink, thanks for the screenshot. It looks like you are using the Advanced CMake subsystem (that is the recommended way) that uses the toolchain path to cache toolchain-specific directories. If you installed the new toolchain in the same directory, it would indeed try to use old cached paths. The workaround is very straight-forward: just delete the \.visualgdb subdirectory and reopen the solution. We have also fixed it on our side, so VisualGDB will now check both the toolchain version and the toolchain directory when deciding whether to reuse the cache.
I cannot figure out why the sepdk build-driver continues to fail with a very basic error. On a Fedora 35 machine, I installed the intel-oneapi-vtune package and the sep5 installation failed. No problem, this has happened before so I started installing it using the instructions here: -help/top/set-up-analysis-target/linux-targets/build-install-sampling-drivers-for-linux-targets.html. But this fails due to it not knowing where to find stddef.h, which is very surprising. Can someone point me to what is going wrong here?
I was able to get VTune 2022.2 to work on Fedora 35 with some help from Vishnu et al. in some internal discussions. Let me describe all of the steps here in one place in case anyone else attempts to do this. I hope that in future releases the installation is improved.
VTune will try to load all of these kernel drivers at boot time using systemd; right now, sudo systemctl restart sep5 fails with a permission error (once I hack around some more unsupported shell syntax). So for now I will manually install the kernel modules with insmod-sep. Hopefully this helps anyone else running into the same issue. VTune team: please make this process less painful!
Jaideep, thanks for the link. I think we should up-level a request to provide some kind of support for Fedora--here's why: I have two Fedora 35 machines and one has a working VTune 2022.1 installed and the other (mentioned above). I don't know how the first one has a working installation (maybe it was an upgrade, maybe I installed the entire base toolkit?) but its existence indicates that it isn't impossible to get VTune 2022.1 working on Fedora. I propose we at least document a way to get VTune working for Fedora with the clear warning that the user is "on their own." Or even better, just support Fedora--why drop it?
I attempted to self-sign pax-x32_64-5.16.14-200.fc35.x86_64smp.ko following the steps outlined here: -US/fedora/f35/system-administrators-guide/kernel-module-driver-configuration/Working_with_Kernel_Modules/#sect-signing-kernel-module-with-the-private-key. But there is no change in result: the signed pax module is still rejected. What to do about this? Is the recommendation to turn off kernel signing or is something else going on here?
We apologize for the delay. Pax driver is actually part of SEP. VTune drivers are unsigned and a secure boot requires cryptographically signed drivers to be used. Could you please share the self-checker log?
You installed the entire basekit? The error you posted is similar to the one I initially had and that seemed to be resolved by installing more of oneAPI tools; I didn't dig into it more than this, since the error went away. But you might want to check that the necessary build environment is set up by sourcing the various environment scripts?
Hm, yeah; not sure what the issue is. I'm also just a user of VTune here. You'll probably want to open a separate issue for this since Manjaro is a different OS. I'm interested to see what the root cause of this is, though.
Glad to know that your issue is resolved. Thanks for sharing the solution with us. If you need any additional information, please post a new question as this thread will no longer be monitored by Intel.
Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.
This section is optional, for readers who want to get ns-3 up and runningas quickly as possible. Readers may skip forward to the Introductionchapter, followed by the Getting Started chapter, for a lengthiercoverage of all of this material.
An ns-3 user will obtain the ns-3 source code (see below),compile it into shared (or static) libraries, and link the libraries tomain() programs that he or she authors. The main() program is wherethe specific simulation scenario configuration is performed and where thesimulator is run and stopped. Several example programs are provided, whichcan be modified or copied to create new simulation scenarios. Users alsooften edit the ns-3 library code (and rebuild the libraries) to changeits behavior.
ns-3 is distributed in source code only (some binary packages exist butthey are not maintained by the open source project). There are twomain ways to obtain the source code: 1) downloading the latest releaseas a source code archive from the main ns-3 web site, or 2) cloningthe Git repository from GitLab.com. These two options are described next;either one or the other download option (but not both) should be followed.
The ns-allinone directory has some additional components but we are skippingover them here; one can work directly from the ns-3 source code directory.The rest of the tutorial describes the additional components.
Once you have obtained the source either by downloading a release or bycloning a Git repository, the next step is toconfigure the build using the CMake build system. The belowcommands make use of a Python wrapper around CMake, called ns3, thatsimplifies the command-line syntax, resembling Waf syntax. Thereare several options to control the build, but enabling the example programsand the tests, for a default build profile (with asserts enabled andand support for ns-3 logging) is what is usually done at first:
All tests should either PASS or be SKIPped. At this point, you have aworking ns-3 simulator. From here, you can start torun programs (look in the examples directory). To run the first tutorialprogram, whose source code is located at examples/tutorial/first.cc,use ns3 to run it (by doing so, the ns-3 shared libraries are foundautomatically):
To continue reading about the conceptual model and architecture of ns-3,the tutorial chapter Conceptual Overview would be the next natural placeto skip to, or you can learn more about the project and thevarious build options by continuing directly with the Introductionand Getting Started chapters.
The purpose of this tutorial is to introduce new ns-3 users to thesystem in a structured way. It is sometimes difficult for new users toglean essential information from detailed manuals and to convert thisinformation into working simulations. In this tutorial, we will buildseveral example simulations, introducing and explaining key concepts andfeatures as we go.
ns-3 has been developed to provide an open, extensible network simulationplatform, for networking research and education. In brief, ns-3 providesmodels of how packet data networks work and perform, and provides asimulation engine for users to conduct simulation experiments. Some of thereasons to use ns-3 include to perform studies that are more difficultor not possible to perform with real systems, to study system behavior ina highly controlled, reproducible environment, and to learn about hownetworks work. Users will note that the available model set in ns-3focuses on modeling how Internet protocols and networks work, butns-3 is not limited to Internet systems; several users are usingns-3 to model non-Internet-based systems.
ns-3 is designed as a set of libraries that can be combined togetherand also with other external software libraries. While some simulationplatforms provide users with a single, integrated graphical userinterface environment in which all tasks are carried out, ns-3 ismore modular in this regard. Several external animators anddata analysis and visualization tools can be used with ns-3. However,users should expect to work at the command line and with C++ and/orPython software development tools.
d3342ee215