Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input for building with MingW + windows #2194

Closed
xyphro opened this issue Mar 16, 2020 · 15 comments
Closed

Input for building with MingW + windows #2194

xyphro opened this issue Mar 16, 2020 · 15 comments

Comments

@xyphro
Copy link

@xyphro xyphro commented Mar 16, 2020

Hi!

I just try to build Verilator 4.030 with MingW/Msys2 under windows and want to share some input to improve experience:

File V3Os.cpp: Change the include of winnt.h to windows.h
Add those libaries to linking phase: -lpsapi -lbcrypt (=>psapi & bcrypt)

Thanks for making such a great and versatile swiss-army knife like of tool!

Best regards,

Kai

@xyphro xyphro added the new label Mar 16, 2020
@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Mar 16, 2020

Thanks, would you mind please submitting this as a patch, then we can be sure to get it right.

Do the libraries perhaps need runtime checks in configure? Are you sure bcrypt is needed?

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

Ah, thank you! I was wondering why verilator was giving an impressive amount of errors when compiling -- replacing winnt.h with windows.h does indeed fix the build.

Did this used to work, and a recent change has broken it? Are there users who regularly build for Windows who would have caught this? Basically, I'm wondering who we would inconvenience by changing #include <winnt.h> to #include <windows.h>.

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

Additionally, bcrypt appears to be necessary, and psapi is necessary in order to get memory usage:

rm -rf ../../bin/verilator_bin_dbg ../../bin/verilator_bin_dbg.exe
g++ -L/lib -static-libgcc -static-libstdc++ -Xlinker -gc-sections -o ../../bin/verilator_bin_dbg Verilator.o V3Active.o V3ActiveTop.o V3Assert.o V3AssertPre.o V3Ast.o V3AstNodes.o V3Begin.o V3Branch.o V3Broken.o V3CCtors.o V3CUse.o V3Case.o V3Cast.o V3Cdc.o V3Changed.o V3Clean.o V3Clock.o V3Combine.o V3Config.o V3Const__gen.o V3Coverage.o V3CoverageJoin.o V3Dead.o V3Delayed.o V3Depth.o V3DepthBlock.o V3Descope.o V3EmitC.o V3EmitCInlines.o V3EmitCSyms.o V3EmitCMake.o V3EmitMk.o V3EmitV.o V3EmitXml.o V3Error.o V3Expand.o V3File.o V3FileLine.o V3Gate.o V3GenClk.o V3Global.o V3Graph.o V3GraphAlg.o V3GraphAcyc.o V3GraphDfa.o V3GraphPathChecker.o V3GraphTest.o V3Hashed.o V3Inline.o V3Inst.o V3InstrCount.o V3Life.o V3LifePost.o V3LinkCells.o V3LinkDot.o V3LinkJump.o V3LinkLValue.o V3LinkLevel.o V3LinkParse.o V3LinkResolve.o V3Localize.o V3Name.o V3Number.o V3Options.o V3Order.o V3Os.o V3Param.o V3Partition.o V3PreShell.o V3Premit.o V3ProtectLib.o V3Reloop.o V3Scope.o V3Scoreboard.o V3Slice.o V3Split.o V3SplitAs.o V3SplitVar.o V3Stats.o V3StatsReport.o V3String.o V3Subst.o V3Table.o V3Task.o V3Trace.o V3TraceDecl.o V3Tristate.o V3TSP.o V3Undriven.o V3Unknown.o V3Unroll.o V3Width.o V3WidthSel.o  V3ParseImp.o V3ParseGrammar.o V3ParseLex.o V3PreProc.o   -lpthread -lm
D:/Software/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: V3Os.o: in function `V3Os::trueRandom[abi:cxx11](unsigned long long)':
D:\Code\verilator\src\obj_dbg/../V3Os.cpp:258: undefined reference to `BCryptGenRandom'
D:/Software/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: V3Os.o: in function `V3Os::memUsageBytes()':
D:\Code\verilator\src\obj_dbg/../V3Os.cpp:297: undefined reference to `GetProcessMemoryInfo'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [../Makefile_obj:276: ../../bin/verilator_bin_dbg] Error 1
make[2]: Leaving directory '/d/Code/verilator/src/obj_dbg'

Furthermore, for whatever reason /usr/include isn't included in my mingw include path by default, so I had to add -I/usr/include to my CPPFLAGS definition.

Finally, as xyphro reported, it didn't link until I added -lpsapi -lbcrypt to my LIBS definition -- adding it to LDFLAGS didn't work, as they need to go at the end of the linker invocation.

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

Oh, one more thing: pod2man wasn't in my PATH.

After replacing #include <winnt.h> with #include <windows.h>, I had to run configure with the following script:

$ PATH=$PATH:/usr/bin/core_perl LDFLAGS="-static" CFG_LIBS="-lpsapi -lbcrypt" CPPFLAGS="-I/usr/include" ./configure --target x86_64-w64-mingw32-gcc

Note that ./configure --help is incorrect. It says that you can set LIBS as an environment variable and it will be added to the build alongside CPPFLAGS and LDFLAGS. This appears to be incorrect. The actual variable name is CFG_LIBS.

@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Mar 29, 2020

Would you mind turning the fixes into a pull request?

Login again to see if pod2man then works, if not you might want to file a bug with the MingW developers to fix it.

I'm not sure how to fix the LIBS documentation as this is made by configure itself and seems their bug, but am looking into it.

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

I can turn the fix for src/V30s.cpp into a pull request, however what is the best way to add -lpsapi -lbcrypt to the LIBS variable?

@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Mar 29, 2020

Try this, this should also make LIBS work.


diff --git a/configure.ac b/configure.ac
index fc90f8179..929b6203e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -370,8 +370,13 @@ AC_SUBST(CFG_LDFLAGS_SRC)
 # The pthread library is required by tcmalloc, so add it if it exists. If it
 # does not, the tcmalloc check below will fail anyway, and linking against
 # pthreads is harmless otherwise.
+CFG_LIBS="$LIBS $CFG_LIBS";
 _MY_LDLIBS_CHECK_OPT(CFG_LIBS, -lpthread)

+# Check libraries for MingW
+_MY_LDLIBS_CHECK_OPT(CFG_LIBS, -lbcrypt)
+_MY_LDLIBS_CHECK_OPT(CFG_LIBS, -lpsapi)
+
 # Check if tcmalloc is available based on --enable-tcmalloc
 _MY_LDLIBS_CHECK_IFELSE(
   $LTCMALLOC,

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

Updating mingw (pacman -Syu) and reloading it seems to have fixed the PATH issue. Good call there.

Is there supposed to be a ; at the end of +CFG_LIBS="$LIBS $CFG_LIBS"; above?

@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Mar 29, 2020

That ; shouldn't be needed.

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

It appears to fix the libs issue (in that now -lbcrypt -lpsapi is added to the command line), however it's still not including /usr/include/. That appears to be a mingw bug, since the default include path is /mingw64/include but the flex package is putting the include file into /usr/include/.

I've tried to file an issue for flex at https://osdn.net/projects/mingw/ticket/40291

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 29, 2020

PR generated.

Tested by configuring with:

$  LDFLAGS="-static" CPPFLAGS="-I/usr/include" ./configure --target x86_64-w64-mingw32-gcc
$
@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Mar 29, 2020

With #2214 and #2215 merged is this all done?

@xobs

This comment has been minimized.

Copy link
Contributor

@xobs xobs commented Mar 30, 2020

It's done for me. Does it fix it for you, @xyphro ?

@Xyp

This comment has been minimized.

Copy link

@Xyp Xyp commented Mar 30, 2020

Had a busy weekend and could not spend time yet on it. Will try today and let you know.

@wsnyder

This comment has been minimized.

Copy link
Member

@wsnyder wsnyder commented Apr 2, 2020

Assuming this is ok now with #2214 and #2156

@wsnyder wsnyder closed this Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.