I am attempting to build the KAT's for the round 3 submission for Classic McEliece, based off the reference implementation on this site:
https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/round-3-submissions
When I try and build it, I get the error:
libkeccak.a.headers/SimpleFIPS202.h
I have attempted to build XKCP by cloning this repo: https://github.com/XKCP/XKCP
and running: make generic64/libXKCP.a
I can see that this builds, and I get a directory within the repo ./bin/generic64/libXKCP.a.headers
Has the name of this project changed since the round 3 submissions were released, or should I be looking for a different repository?
If this is correct, I still cannot build Classic McEliece, even if I change all references from libkeccak.a.headers/SimpleFIPS202.h to libXKCP.a.headers/SimpleFIPS202.h
Do I need to move this directory: ./bin/generic64/libXKCP.a.headers somewhere to allow gcc to find it? (I am on wsl)
Managed to fix it myself.
This question helped me: C++ Using Keccak Library
I had to clone those repos to the correct spot.
Then you need to change the include from libkeccak.a.headers/SimpleFIPS202.h to libXKCP.a.headers/SimpleFIPS202.h , as I guessed.
After that, you also need to change one of the flags in compilation from -lkeccak to -lXKCP (I couldnt find a reference anywhere, so this was a guess, but it worked.)
Related
I am about to test GHDL and Yosys as a replacement of EDA proprietary design flows, for my students. My point is about VHDL synthesis.
I have a fresh install of several tools : trellis (ECP5), yosys, nexpnr, fujprog (ulx3s).
GHDL is also installed for a longer time but it is supposed to include synthesis also (--synth option works).
ghdl -v
GHDL 1.0-dev (v0.37.0-208-g2c66a8bd) [Dunoon edition]
Compiled with GNAT Version: Community 2019 (20190517-83)
llvm code generator
It seems that I also need ghdl-yosys-plugin. However, the install does not work for me.
I get a bunch of error messages :
make GHDL=/opt/ghdl/bin/ghdl
yosys-config --exec --cxx -c --cxxflags -o ghdl.o src/ghdl.cc -fPIC -DYOSYS_ENABLE_GHDL -I/opt/ghdl/include -O
src/ghdl.cc:361:2: error: unknown type name 'Attribute'
Attribute attr = get_first_attribute (inst);
^
src/ghdl.cc:361:19: error: use of undeclared identifier 'get_first_attribute'
Attribute attr = get_first_attribute (inst);
^
src/ghdl.cc:379:7: error: use of undeclared identifier 'Id_Posedge'; did you mean 'Id_Edge'?
case Id_Posedge:
^~~~~~~~~~
Id_Edge
etc
I am missing something. Can someone help ?
Thanks in advance
JCLL
As I suspected (despite versioning that seemed correct), a fresh new install of GHDL fixed the issue.
i did some investigating: ghdl has undergone some restructuring, for proper FHS compliance. for example this commit https://github.com/ghdl/ghdl/commit/66cd5e0aa897b947533d269535fde4c0852472c2 and further commits show some renaming which ensures compliance with FHS conventions. files that used to be installed as /usr/local/include/ghdhsynth.h are now in /usr/local/include/ghdl
however because there are two completely separate pieces of software involved here (ghdl and yosys-ghdl-plugin) you have to (a) keep them in sync and (b) ensure that prior-installed ghdl headers are manually cleared out HOWEVER
manually deleting the installed files in /usr/local/include and reinstalling may not help if you cross over the threshold of commits from stable to developer releases on one but not the other, because older versions of yosys-ghdl-plugin were also not FHS convention-compliant. or, if you don't get them exactly right (i had to check the git log commit timestamps for both ghdl and ghdl-yosys-plugin in order to get a match), you get the general idea
if you really want to use a mis-matched version of ghdl and ghdl-yosys-plugin (YMMV here) then there are a few solutions:
manually copy the files in /usr/local/include/ghdl into /usr/local/include. this is a really dreadful hack that will need repeating each time you re-install ghdl.
modify the yosys-ghdl-plugin Makefile to include "-I/usr/local/include/ghdl" in CFLAGS or ALL_CFLAGS
in ghdl/synth.h and anywhere you see ghdl/synth.h used replace it with just "synth.h", likewise with synth_gates.h.
bear in mind that all of these are absolutely awful, totally not guaranteed to work, and you are way better off making sure that the versions being used are properly in sync.
it also does not help that some things from yosys latest master are also being removed, on which yosys-ghdl-plugin relies, to compile! as of writing i have found that tag yosys-1.13, ghdl-plugin commit c9b05e481423c, and ghdl commit 263c843ed49 will compile and work. however if i update to latest ghdl master (0e46300) microwatt fails to build, so i am sticking with 263c843 for now.
YMMV, hopefully however that gives you some insights rather than considering these complex and fantastically useful pieces of interlinked software to be opaque black boxes.
Since I started using CocoaPods, I've been having weird location related messages all the time, and some arch-related ones too.
I've been trying the whole day to figure out why it was happening, until I create a new Xcode project from scratch and realize the issue wasn't project-related all along.
Here's what's happening:
I always get those everywhere as well:
Not sure if related but I get those often too:
Anybody has those as well? What should I do?
Thanks!
I had to switch Build Active Architectures Only for debug to Yes and it let the build run.
I'm having some serious problems compiling. I'm on Xcode 5. Everything was working, now it's not.
It won't compile my .pch file. I've tried a new .pch file to no avail.
I get hundreds of errors, starting with: Unknown type name 'intmax_t'
Has anyone experienced this and got any pointers to where I might start figuring out why it's doing this? It's got to be a setting in my project file somewhere
that error comes from "stdint.h" not being in your project. (that's where it's defined). Since that's a core library, it must be that a path has changed some how. This could happen if you moved your project, renamed the folder, or installed a new version of Xcode and the path is not updated. It could also happen if the compiler settings were changed. for example, see this question
Xcode 4: "error: unknown type name 'BOOL'; did you mean 'BOOL'?"
as you can see, his compiler was switched on him and he had to change it back. So you might be using a different compiler without realizing it, so it's looking for the libraries somewhere else. That you give you some clues. Let me know what you find
I found the issue to be:
Always Search User Paths: This was set to Yes.
User Header Search Paths: "$(SRCROOT)/" (recursive)
I removed these and all is well again.
I have a really strange problem with intellij-idea. When running some main function in my java program intellij creates a directory called out to store the class files along with a few other things.
the directory it creates has the following structure
<PROJECT_ROOT>/out/production/<PROJECT_NAME>/
nothing weird there, HOWEVER, when I run the program inside intellij again, it creates an NEW out directory with the same structure inside the directory so the result is as follows
<PROJECT_ROOT>/out/production/<PROJECT_NAME>/out/production/<PROJECT_NAME>/
then if I run it again it nests ANOTHER one!
<PROJECT_ROOT>/out/production/<PROJECT_NAME>/out/production/<PROJECT_NAME>/out/production/<PROJECT_NAME>/
and so on...
This is incredibly frustrating behavior to say the least. i thought it might be my environment (Windows) so I set the project on my linux box, and observed the same behavior. I did clone this project from a git repo but I dont think that would be the cause. I have noticed the same behavior in different projects i have cloned as well.
My next step is to create two entirely differnt projects from scratch in each environment and see if I can reproduce the problem that way. I will update this post with results once I have tried that along with anything else I try, but I thought i would post here while I continue trouble shooting just in case anyone else has seen this behavior and knows a solution.
i will keep this updated as I go. Any "idea" (see what I did there ;) or suggestions are appreciated!
UPDATE
creating a hello world prog from scratch on the linux box did not reproduce the behavior.
UPDATE creating a hello world prog from scratch on the Windows box did not reproduce the behavior.
I was able to reproduce this. When the base module is also the src root, IntelliJ will behave this way. If you unmark the base module as src root, and then create a src directory to put your source files in, you will notice that on the next compile that whole directory structure gets blown away and IntelliJ goes back to behaving sensibly.
I've got a really strange error and any light that anyone can shed on this would be greatly appreciated.
I made some changes to some VB6 source which builds a COM object. The automated build which builds our app returned an error. No problem I thought--I'll just back out my changes. Well backing out my changes isn't making the problem go away.
Specifically when I attempt to build the app via a .vbg file, with a command line like path\to\vb6\vb6 ProjectFile.vbg /make
I get a message
"Compile Error in File '', Line : Object library
invalid or contains references to object definitions that could not be
found."
As I said, I reverted the source code so I'm really stumped as to why this error is still occurring. Any VB6 gurus around who might be able to point me at an answer?
I can post the exact code in question but the fact that it was building correctly, stopped building correctly and now refuses to build correctly makes me think this is not a problem with my code but rather some problem in the environment. Like something got put in the registry as a result of the previous build error.
Any tips, hints, or suggestions greatly welcome. I realize my question is a bit sketchy but I'm not even sure what's important to include and what isn't.
EDIT 1:
Thanks for the excellent suggestions guys. I think it is something to do with VB6 doing some sort of auto-registration.
Just to add a bit more detail: this problem does not occur when I build the referenced vbp file from the IDE. It only happens on the make on the .vbg which contains the vbp. Also the build tool in question automatically pulls latest source and the error happens on both my local box and the dedicated build box.
EDIT 2:
Hi again all,
The release engineering fellow figured out how to get this to build in his build environment so it's currently ok. Once we're past this crunch, I'll try to interrogate him about what he did and share the details with everyone.
Thanks again for all the great suggestions. This is what's so great about SO; that is, I asked about a 10-year-old technology and I got several great and on-point ideas.
Make sure that the VBG and all the VBP's got rolled back as well. That error is consistent with a project trying to reference a CLSID that is no longer valid for the dependency. Have you tried loading up the project group and building from the IDE, if that works and you save and check in all the changes to the group and project files, you might be fixed up.
I'm guessing the fact that you mention that it was a COM component might be the source of the problem. If any of the public method's or properties have changed then I seem to remember that VB6 will change the interface GUIDs and auto register the new ones.
My suggestion would be to check the registry to look for any mention of the component name, make a note of any associated CLSIDs, back up the registry, and then delete the references.
As cmsjr mentions it could also be a bad CLSID reference in your .vbp files.
The other option is that the failure has caused a problem with some .tlb (type library) or olb (object library) files.
The best thing to do is move all your compatibility DLL to a separate and combined directory. The reason for this is control over what VB6 is using to check for binary compatibility. In addition the Typelibs that are generated IMPORT the references. So if you using Binary DLL Ver 10 for compatibility however the import is pulling in Binary DLL Ver 9 you will have issues. By keeping all the libraries in a single folder and pointing your projects to the DLLs in that folder you ensure that the respective TypeLib Import the correct version.
Finally if you have multiple levels of DLL reference each other. You may run into mysterious error where the VB6 is unable to compile using binary compatibility. In such cases you need to compile the lowest DLL in the hierarchy (Utility DLL perhaps) copy it over into the compatibility folders. Work your way up the chain until everything compiles in one shot again.
This is because if have DLL A reference DLL B which Reference DLL C. VB6 will get sometimes get confused if you make a change to A and C. will compile fine but A will not until the compatibility libraries are updated.
Hunt down and delete any .obj and .exp files that may be lying around from the previous failed build.
You will have to open the project & re-type in the lines that you changed.
Save the project alongwith VBG and re-compile after that.
I think that will fix it.
EDIT: The idea is that the cls/bas file remember the class (CLSID) that you used. So, if you change the references but don't change the lines in the cls/bas - it is a mismatch of type (what was referenced vs what is typed in cls/bas file).