libleveldb.a not generated on Windows build - docs problem? #1964
Comments
|
If you are native on Windows, you should just comment out from https://github.com/bitcoin/bitcoin/blob/master/bitcoin-qt.pro#L97 up to line 111, as this currently doesn't work on Windows. I guess you have MinGW installed, so you are able to compile LevelDB via MinGW Shell.
I also needed to edit the Edit: Pull #1940 is related to this, perhaps you want to take a look there, too. |
|
The Boost version I have came in the deps zip, referred to in the That zip is signed by Witchspace witchspace81@gmail.com so I'm contacting him to see if he has a zip with a consistent set of boost files. I think either when he compiled some of the boost headers were unnecessary, or else he failed to include them in the dependencies archive he made. It's complaining with So I will try compiling the latest boost on my own like you did. |
|
I was able to compile the boost libraries I need, but only under Windows - making .lib files, not .a files. I suppose that's no good for compiling bitcoin-qt under mingw. I see three options and I wonder which one might be best:
Any recommendations? |
|
I would vote for 1), as there is currently no core-dev using Windows as native OS, which means the deps-package won't get an update. I compiled Boost only using Windows command-line, which IS a pain ^^. |
|
Note that you need msys/mingw. You can run mingw compilation from cygwin,
|
|
It would be the Boost libraries that I'd compile under Cygwin, and then |
|
I got cygwin, and started following the instructions for compiling boost libraries (http://www.boost.org/doc/libs/1_51_0/more/getting_started/unix-variants.html - note that the Cygwin bash shell puts me on a POSIX platform) and got an error indicating that bash was trying to execute blank lines: "$'\r': command not found in Cygwin" Tamil's post helped with that. I'm now converting all the boost code to unix line endings and will keep y'all posted. I still assume I'm making some boneheaded mistakes and hoping someone will point them out. That's why I'm posting my progress. For example, is it reasonable to expect the Boost libraries that I compile under cygwin to be valid for use under MinGW when I use them to build the LevelDB libraries? And then to expect those leveldb libraries to work when I compile bitcoin under QT? There's some compiler static/dynamic linking / architecture stuff going on there that daunts me. And something I read somewhere suggested that code compiled under Cygwin often requires the Cygwin dll to work. |
|
My two cents: Combining multiple tool chains (e.g. mingw and cygwin, or mingw and visual studio) is a bad idea. Try to compile everything with the same compiler. I would very much like to see somebody figure out how to make everything build with the Visual Studio toolchain, because I think that is the toolchain the vast majority of Windows programmers already have. That is a big project, though... |
|
@dscotese Yes you need to build everything against MingW libs. If any part links against Visual C or MingW, undebuggable madness ensues. As a plus, you will learn a lot about linker internals 🐸! @gavinandresen I have a build for bitcoind + bitcoin-qt + most deps (everything in one project for easy building) for VS somewhere, but my Visual Studio trial license expired along the way (and there's no way I'm going to put any money into it). Alternatively (it's the option I prefer at the moment) is that we add a cmake build system and let it generate all the build scripts for all platforms for us. qmake scales very badly to big projects and is starting to show its seams, and will likely be deprecated somewhere along the road to Qt5. I may get around to this. |
|
I don't have the need for or the feeling to miss MS Visual C++ support, I'm loving my MinGW / Qt Creator toolchain :). What I would love to see is a working solution to compile LevelDB via that toolset. I'm able to compile OpenSSL, BDB and Boost dependencies, which is all I need. Currently LevelDB was build via the MinGW shell, which is okay, but this process is not all that smooth. Well it doesn't really matter, as we seem to not update the LevelDB code that often anyway. |
|
@dscotese This is how I build the boost libs with MinGW on Windows: Example for Boost 1.49 extracted to D:\boost_1_49_0 in my case!
open D:\boost_1_49_0\bootstrap.bat open D:\boost_1_49_0\tools\build\v2\engine\build.bat and search for replace existing code with: My MinGW installation resides in open You can also just use the Windows command-promt ( enter This builds b2, the Boost build engine V2! create the libs needed by Bitcoin: This should create all *.a files you need for Bitcoin-Qt and they can be found in Hope this helps! |
|
Very helpful. I balked when I saw that Boost hadn't tested MinGW, and that's why I went to Cygwin. But I just followed your instructions and they worked perfectly. Below are some edits (in bold)
That created the .a files, which I then put into Now I will try to compile bitcoin-qt. |
|
I'm getting two errors, one insinuating that the compiler was passed -fno-rtti (and then the code tries to use runtime typing), and the other that insinuates that exception handling is disabled by default. Where do I look to alter the flags passed to the compiler? |
|
I'm glad you could figure out that Boost stuff now, btw. @laanwj do you think it makes sense to keep that howto somewhere in the doc folder? Are you using the default MinGW that ships with the Qt SDK? My toolchain is using -rtti, which is coming from |
|
Once you get everything working properly, please update doc/build.msw.txt and doc/readme-qt.rst and submit a pull request so we don't forget all of your hard work to get this all working properly. |
|
I installed MinGW before I installed QT, to the root of C, so I compiled the Boost libs with the MinGW in the root of C. There are only 4 items in my @gavinandresen The instructions for Windows have a step to download the dependencies archive, which has an old version of Boost in it. Do you recommend updating the archive with the newer version, or updating the instructions to include compiling version 1.51 of the Boost files we need? Since compiler output includes errors that will disappear when earlier errors are fixed, I'm only posting the first chunk of it here. Let me know if the errors listed are ones I can ignore (and if it's easy to suppress them on the grounds that they are useless, how do I do that?): |
|
AFAIK in order to use a custom MinGW version you also need to build the Qt libs with that MinGW version, did you do this? Can you open command-prompt and enter |
|
Regular DOS command prompt and QT4.8.3 Command prompt and the MinGW Shell all produce the same output: I am working through the instructions at http://qt-project.org/wiki/Building_Qt_Desktop_for_Windows_with_MinGW in order to compile QT for Win32 - I'm on Windows 7 64 bit, but as g++ above shows, the target is 32 bit so I guess I'll be cross compiling. Doesn't matter to me. What I want to do is get bitcoin-qt to compile so I can debug it. The instructions insinuate that there are "mingw contents" in the SDK. I installed the SDK 5 days ago and as I wrote in an earlier message, "I think my QT installation detected my existing MinGW installation and didn't install its own." Does that make sense? If that is the case, then can I expect the build of QT to succeed by changing the path to MinGW32_x86 from The instructions also said to copy Perl into the build directory. My perl comes from my installation of git (git\bin\perl.exe), so I copied the entire git\bin directory to I got this error while executing _clear87 and _control87 are declared in float.h in standard C, I learned from Digital Mars (http://www.digitalmars.com/rtl/float.html), but there is no float.h in the QT build directory. In fact there is no file except qlocale.cpp that has _clear87 in it. So I must be missing some source that declares it. Where could that be? Maybe MinGW32_x86 would have had it... I found it in c:\mingw\include\float.h. Is configure.exe supposed to run some of the bin files in mingw32_x86 and in that way discover the header files in its include directory? That seems odd. Help?? |
|
Alright, so let's do a step-by-step for getting Qt compiled on Windows with an own MinGW (which you indeed have).
Hope this helps :). |
|
Thanks for the instructions, and the pointer that 4.8.3. has a qmake problem with resource files. I'm working on compiling Qt as I type this. I asked a bunch of questions and I think your instructions answer some, but I wanted to check that I understand: Is it reasonable to expect the Boost libraries that I compile under cygwin to be valid for use under MinGW when I use them to build the LevelDB libraries? Answer from Gavin and laanwj: No. Use the same toolchain for everything. As per Diapolo, that would be MinGW/QTCreator. Followup question: MinGW is the compiler, and QTCreator is the IDE, right? I think my QT installation detected my existing MinGW installation and didn't install its own. Does that make sense? I got no direct answer, but Diapolo provided instructions on building QT4.8.2 with a custom install of MinGW, so I'm assuming QT detected the existing install and skipped its own. [T]here is no file except qlocale.cpp that has _clear87 in it. So I must be missing some source that declares it. Where could that be? I answered this one myself. My custom MinGW install had it in float.h in its own include directory. Is configure.exe supposed to run some of the bin files in mingw32_x86 and in that way discover the header files in its include directory? I think the answer is no, and that the problem with the float.h file is a bug in the QT 4.7.4 source that requires MinGW to be at |
|
The configure.exe command worked, but it's I just started the compile. http://doc.qt.digia.com/qtcreator-2.4/creator-project-qmake.html describes how to use different versions of QT in QT Creator. Pretty cool to see all those processes pop up in the task manager. |
|
The really important thing is you need to build everything with the same MinGW version, this starts from the libs, to Qt (and Qt Creator can also be build for yourself), leveldb and the client itself. So MinGW is the compiler and Qt Creator is your used IDE. From what you are writing I think you have 2 MinGW versions, which could mess things up here. I for example just have the one that I installed via the Configure.exe builds qmake afaik and needs the compiler and linker, so yes it's normal it's starting binaries from the MinGW installation :). |
|
I got it compiling, but when I tried to run it, I got "During startup program exited with code 0x0000c135". I used ProcessViewer to determine that this is because miniupnpc.dll isn't in the path. Bitcoin-qt.pro had MiniUPNP enabled by default, and I don't see miniupnpc.dll in my bitcoin installation directory, so I'm guessing that it's supposed to be linked into the bitcoin-qt.exe ("statically linked", right?), but when I compiled, this didn't happen - at least for the debugger, it wants to find miniupnpc.dll on the path somewhere. As you will see in the instructions (when I figure out how to make them available), I haven't addressed this issue in there yet. Is my guess correct about the linking of miniupnpc? I'm pretty green on git, so here I've copied the commands I used so far to try to make my changes to readme-qt.rst available to anyone who wants to check it: master -> master ??? I thought I just created the ds_native_windows branch? But I guess I also pushed it to the master (which is the only) branch on my dscotese/bitcoin fork. Is that correct? |
|
After adding miniupnpc.dll to by bitcoin debug directory, I can start the debugger, but I get a SIGSEGV right away on this line in db.cpp: |
|
You didn't check out your branch at first, perhaps that's why you see |
|
I added "USE_UPNP=-" - QT Creator now reports my qmake command line as Line 33 in net.cpp says If I understand the output of git diff on the last commit of net.cpp (8bb5edc), net.cpp was first added in that commit, as well as the lines in bitcoin-qt.pro that (I thought) should indicate how to avoid compiling ThreadMapPort2. Either the instructions are wrong or I'm missing something here. Perhaps what I'm missing is that "USE_UPNP=-" means don't put anything after the =. I tried "USE_UPNP=" and it compiled, but it still gets the same segfault I reported earlier when I try to debug it. But "USE_UPNP=" is the same as not adding anything, isn't it? I found a reference to the USE_UPNP in \doc\build-msw.txt: Also, you said I hadn't checked out my branch, and that made sense to me, but it says I'm already on it and it lists the commit: So I don't know how to make my ds_native_windows branch available to you so you can see the edits I made to the section on building under Windows. I'll post it here if you want, but I'd rather use it to figure out how to make stuff available through git. |
|
I think the problem I ran into with the USE_UPNP flag was that I didn't clean the project, so it didn't end up recompiling net.cpp. I deleted the net.o file and rebuilt and that generated a successful compile with Next theory is that I've compiled with different toolchains. QT does list two MinGWs, but the only differences is that the one I've selected for this build specifies a Debugger (the other one, auto-detected, is called "MinGW (x86 32bit)" instead of just "MinGW", and has no Debugger), but the Compiler path and ABI are the same for both. Oh, except for the case of the directory name (auto-detect gets mingw, and the one I entered is MinGW). So I assume QT is listing the same toolchain twice. Maybe I used something else to compile one of the libraries I'm using. Hmm... the files in the Dependencies zip included more than just the boost libraries - crypto, db, and ssl. I guess I need to compile all of them with my Mingw. So that's my next step. I am using this issue as a sort of weblog, but if there's a better place for me to log my progress for others who want to see someone climb this learning curve, let me know and I'll put it there instead. |
|
@dscotese Why not backup your modifications in your Git-branch by simply copying them out of the used directory, delete your branch and start with a clean master branch.
Great you figured out the USE_UPNP stuff, when chaning such things it's always a good idea to cleanup via the Qt Cretor IDE, which has a menu point for that under You indeed need to build ALL dependency packages with your compiler, if you want to be successful in building Bitcoin-Qt. The ones you need are BDB, Boost, OpenSSL, Qt and leveldb. I'm fine with your blog-style here :). |
|
Here are the relevant additions to the readme-qt.rst file:
If you want to skip miniupnp, you can, just remember to add USE_UPNP=- to the switches on qmake in QT Creator when you build bitcoin-qt. If you want miniupnp, try this (not yet proven):
.. _ This compiles, but when I debug the result, it immediately fails with the same segmentation fault I described earlier. |
|
You wrote you are observing a segfault, but did you ever build a release version in Qt Creator? The used debugger is GDB, which you also can compile for yourself, so perhaps just try a release build before. Which version of Qt Creator are you using? Was it build by your toolchain or did you download that? |
|
I don't understand "so perhaps just try a release build before." Do you mean that IF the release build works as expected, then I can assume the debugger needs to be compiled with the same version of QT that I used to compile bitcoin-qt? I suppose that makes sense. The gdb being used was last written about 2 months before I posted this issue, so clearly, I'm not using a gdb that I compiled. The attempt to compile the release version issues a warning: C:\Qt\projects\bitcoin\src\qt\qtipcserver.cpp:22: warning: #warning Compiling without BOOST_INTERPROCESS_HAS_WINDOWS_KERNEL_BOOTTIME and BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME uncommented in boost/interprocess/detail/tmp_dir_helpers.hpp or using a boost version before 1.49 may have unintended results see svn.boost.org/trac/boost/ticket/5392 [-Wcpp] They are NOT uncommented, which means they aren't in effect, and perhaps boost's interprocess does have the kernel boottime (whatever that means). There is no commented define for these macros in the indicated file, so I'm a little lost. I just added #defines for them and recompiled and I'm still getting the same segfault. It compiled (mingw32-make.exe exited normally), but when I ran it, it immediately failed with 0x3FFFFECB. How do I figure out what that exit code means? Heh - by debugging. Ok... I watched the registers before I made the release build and determined that A) 0x5ec21b <+0x000b> movl $0xb5ba68,(%ebx)` doesn't move the contents of 0xb5ba68, but rather the value 0xb5ba68, into the memory address stored in %ebx, which is 15!!. It's a base index register, so maybe that is relative to something else, but I'm guessing that whatever memory address it's pointing to isn't accessible and thus the segmentation fault. Please correct any boneheaded things I've said. I'm totally guessing. Guess I try compiling my own gdb next. |
|
Refers to old build system, and boost::interprocess is no longer used, closing |
…aw_shielded_sendmany 634ddbf [Tests][Refactor] Check mempool in sapling_wallet.py (random-zebra) 0673634 [Tests] Add test for raw_shielded_sendmany (random-zebra) 07b666c [RPC] Introduce raw_shielded_sendmany (random-zebra) 30f3a09 [Refactoring] Remove testMode from SaplingOperation (random-zebra) 4b0fd27 [Test] shielded_sendmany: check from_transparent argument in unit test (random-zebra) b8e28f8 [Test] Verify shielded_sendmany with generic fromAddress (random-zebra) 4241fbf [RPC] Add option to send from multiple addresses in shielded_sendmany (random-zebra) 60b7c9b [Trivial][RPC] Fix default fee in shielded_sendmany help (random-zebra) 952555f [Refactor] Introduce CreateShieldedTransaction auxiliary fun for RPC (random-zebra) Pull request description: Add the option to `shielded_sendmany` to automatically select the inputs from any transparent or sapling address (inserting the string `"from_transparent"`/`"from_shielded"` instead of the from-address) Create new rpc `raw_shielded_sendmany` which creates (without committing) the shielded transaction and returns a json object. Update the functional tests. Based on top of: - [x] bitcoin#1961 Starts with `[Refactor] Introduce CreateShieldedTransaction auxiliary fun for RPC` (e014ff3) ACKs for top commit: furszy: ACK 634ddbf and merging.. Tree-SHA512: cd4c3226a1782b86af9bd7915cd75decc94601962c2c40884381118f302bbe35ed2cfefc59962f40e05f5b858b57588edc3cfad7098b13ffbe30e203d801c39f
…plinganchor 60ea1d8 [CI][Tests] Move sapling functional tests to their own list (random-zebra) 03aec32 [Tests] Add sapling_mempool to test_runner and re-sort the list (random-zebra) c3a1fff [Test] Add sapling_mempool functional test (random-zebra) 101978d [RPC] Introduce getbestsaplinganchor to get the most recent sapling root (random-zebra) Pull request description: Based on top of: - [x] bitcoin#1958 - [x] bitcoin#1964 This adds a functional test to check the bahavior of sapling transactions with the mempool. Specifically, it verifies the nullifiers/anchor management introduced in bitcoin#1958: - If a transaction spends a sapling note, already spent by another in-mempool transaction, it's not accepted in the mempool. - Same if it tries to double-spend a note already spent on chain. - If, after disconnecting a block, the sapling merkle tree root changes, any transaction that spends a note referencing the old root must be evicted from the mempool. In order to verify the last point, a simple RPC `getbestsaplinganchor` is introduced in the "blockchain" category. It returns the `pcoinsTip` best anchor. Note: without 1958, the test crashes the node, as two transactions spending the same note can both enter the mempool, but then the assertions in the memory pool consistency checks fail during block creation. ACKs for top commit: furszy: Pretty nice!, code review ACK 60ea1d8 Fuzzbawls: utACK 60ea1d8 Tree-SHA512: c321d7866bec56fca31d48286ac28ae44f27c48232919fd3f66fcc858a558b17cc0580163790c74290f376049fa44391a1033eb582ff9716b502673f535048d6
467b0d8 [Tests] Check delegations with sapling transactions (random-zebra) d412525 [RPC] Add fUseShielded parameter to delegatestake/rawdelegatestake (random-zebra) 847d278 [Trivial] Missing newline in delegatestake (random-zebra) 7440709 [Validation] Don't reject sapling txes with P2CS outputs (random-zebra) Pull request description: Enable pay-to-cold-staking outputs in shielded transactions. Add the option in `delegatestake`/`rawdelegatestake` to spend shielded funds directly to P2CS (without having to unshield them first). Add functional test. Based on top of - [x] bitcoin#1964 - [x] bitcoin#1967 - [x] bitcoin#1969 Starts with `[Validation] Don't reject sapling txes with P2CS outputs` (461d4ea) ACKs for top commit: furszy: Looking good, ACK 467b0d8 Fuzzbawls: ACK 467b0d8 Tree-SHA512: 88752fe1550def605b90cc894d0666f5c37dd8f075566e976c8fbfaa6e088ee0c1bb028e1885411b739781fda6ebac12a5c99fc19a06f453e594441ee1e1b599
I tried building on windows and got this:
error: No rule to make target 'c:/Qt/projects/bitcoin/src/leveldb/libleveldb.a', needed by 'debug/bitcoin-qt.exe'. Stop.
The build-mws.txt, README_windows.txt, and readem-qt.rst files do not make any reference to building the libleveldb.a file outside of the bitcoin build.
I did not separately download and build the four items listed in build-msw.txt, but none of them are leveldb. I downloaded and installed the dependencies as instructed in the readme-qt.rst file.
This led me to lines 100-104 of bitcoin-qt.pro "# make an educated guess about what the ranlib command is called". I'm looking up this "ranlib" thing...
The text was updated successfully, but these errors were encountered: