Trying to emerge litecoin-0.10.2.2 fails with leveldbwrapper.cpp:14:20: fatal error: memenv.h: No such file or directory #include <memenv.h> ^ compilation terminated. distcc[5276] ERROR: compile leveldbwrapper.cpp on localhost failed Makefile:3516: recipe for target 'libbitcoin_server_a-leveldbwrapper.o' failed make[2]: *** [libbitcoin_server_a-leveldbwrapper.o] Error 1 make[2]: *** Waiting for unfinished jobs.... /bin/sh ./libtool --mode=compile --tag YASM ./nasm_lt.sh yasm -f elf64 -I. -I. src/field_5x52_asm.asm -o src/field_5x52_asm.lo libtool: error: ignoring unknown tag YASM is it maybe some missing use flag in leveldb? [I] dev-libs/leveldb Available versions: 1.9.0-r5 1.9.0-r6 (~)1.10.0-r1 (~)1.11.0-r1 (~)1.12.0-r1 (~)1.13.0-r1 (~)1.14.0 (~)1.15.0 1.15.0-r1 (~)1.17 (~)1.18 (~)1.18-r1 {+snappy static-libs +tcmalloc} Installed versions: 1.18-r1(09:07:37 PM 07/08/2015)(-snappy -static-libs -tcmalloc) Homepage: http://leveldb.org/ https://github.com/google/leveldb Description: a fast key-value storage library written at Google Reproducible: Always Steps to Reproduce: 1. try to emerge litecoin-qt
Problem solved (for me and the rude way): # cd /usr/include # ln -s leveldb/helpers/memenv.h Which will leave us with a memenv.h in /usr/include instead of it just sitting in /usr/include/leveldb/helpers Someone might want to fix the litecoin-qt sources there.
@comment 1: Given the quality of your "fix" I'd strongly suspect that one of your previous "fixes" has just bitten you. Anyway, attach full build log and config.log.
The fix criticized(!?) in comment #2 works for me. The indication is that the reported misbehavior is due to either a bug in litecoin-qt 0.10.2.2 or the leveldb 1.18-r1 package as both seem to disagree about the location of memenv.h Closing as it WORKSFORME and we'll prefer to fix buggy Gentoo packages "that way", instead of reading sh*tty allegations.
:sigh: divas... To properly fix a bug, you need to have (among other thing ) sufficient info that the bug really exist and isn't - for example - a result of an invalid user action (like, let's say, putting random stuff in /usr/local). If the reporter first action is to drop a random symlink at a semi-random location without citing the basis for such action, it's a red flag. Asking for a build log in an unclear situation is a standard bug wrangling action (at least in Gentoo). In this particular case, however, what would have sufficed would be the build log and a quote from dev-libs/leveldb 06 Mar 2015 ChangeLog entry. Yet even that little was for some reason too much...:shrug:...
Rafał Mużyło, you've not brought anything to the table, despite spilling shitty allegations. Accusing someone to react on that as a diva - It's a little bit too much. * setting that link wasn't the first action * it was also not a random symlink at a semi-random location * it is deliberately chosen after analysis and litecoin-qt compilation immediately worked * criticizing that action - while at the same time not suggesting what would have been a better action (*) - and strongly suspecting from that some incompetence in the past - is ignorant and rude (*) something to yield same immediate positive result while confirming the underlying problem for the compilation failure. Having used Gentoo since sometime around 2007, we *know* about the standard requirement of sending buildlog and env information. We also know when this is really not necessary - as in this case. And no, we won't send changelog quotes a priori. We are still very optimistic - prehaps even to some naive extent - to meet here competent Gentoo people who also see a little bit further than your favorite level1-support trained ape. That being said, equery reveals that leveldb package brings the memenv.h file in some weird location. My bet would be that the problem is not on litecoin-qt side but on leveldb site. IMHO this is the important information # equery f leveldb * Searching for leveldb ... * Contents of dev-libs/leveldb-1.18-r1: /usr /usr/include /usr/include/leveldb /usr/include/leveldb/c.h /usr/include/leveldb/cache.h /usr/include/leveldb/comparator.h /usr/include/leveldb/db.h /usr/include/leveldb/dumpfile.h /usr/include/leveldb/env.h /usr/include/leveldb/filter_policy.h /usr/include/leveldb/helpers /usr/include/leveldb/helpers/memenv.h /usr/include/leveldb/iterator.h /usr/include/leveldb/options.h /usr/include/leveldb/slice.h /usr/include/leveldb/status.h /usr/include/leveldb/table.h /usr/include/leveldb/table_builder.h /usr/include/leveldb/write_batch.h /usr/lib64 /usr/lib64/libleveldb.so -> libleveldb.so.1.18 /usr/lib64/libleveldb.so.1 -> libleveldb.so.1.18 /usr/lib64/libleveldb.so.1.18 /usr/lib64/libmemenv.so -> libmemenv.so.1.18 /usr/lib64/libmemenv.so.1 -> libmemenv.so.1.18 /usr/lib64/libmemenv.so.1.18 The symlink fixes that current problem actually in a very elegant way because it is a minimalistic manual intervention. Nevertheless we qualified our fix as "rude", because that symlink file is not under package control. The correct fix would probably be to modify include statements in litecoin-qt or setting this link into leveldb-1.18-r2 *We know that* Its exisence alone can be hardly less elegant than: lrwxrwxrwx 1 root root 63 May 28 16:32 /usr/include/ansidecl.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/ansidecl.h lrwxrwxrwx 1 root root 58 May 28 16:32 /usr/include/bfd.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/bfd.h lrwxrwxrwx 1 root root 62 May 28 16:32 /usr/include/bfdlink.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/bfdlink.h lrwxrwxrwx 1 root root 15 Apr 26 2014 /usr/include/cblas.h -> gsl/gsl_cblas.h lrwxrwxrwx 1 root root 8 Jul 8 14:43 /usr/include/cryptopp -> crypto++ lrwxrwxrwx 1 root root 14 Apr 28 08:01 /usr/include/db_185.h -> db6.0/db_185.h lrwxrwxrwx 1 root root 10 Apr 28 08:01 /usr/include/db.h -> db6.0/db.h lrwxrwxrwx 1 root root 63 May 28 16:32 /usr/include/demangle.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/demangle.h lrwxrwxrwx 1 root root 62 May 28 16:32 /usr/include/dis-asm.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/dis-asm.h lrwxrwxrwx 1 root root 65 May 28 16:32 /usr/include/dyn-string.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/dyn-string.h lrwxrwxrwx 1 root root 62 May 28 16:32 /usr/include/fibheap.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/fibheap.h lrwxrwxrwx 1 root root 62 May 28 16:32 /usr/include/hashtab.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/hashtab.h lrwxrwxrwx 1 root root 62 May 28 16:32 /usr/include/libiberty -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/libiberty lrwxrwxrwx 1 root root 64 May 28 16:32 /usr/include/libiberty.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/libiberty.h lrwxrwxrwx 1 root root 9 Apr 28 2014 /usr/include/libunrar.backup.0000 -> libunrar5 lrwxrwxrwx 1 root root 9 Jul 4 2014 /usr/include/libunrar.backup.0001 -> libunrar5 lrwxrwxrwx 1 root root 9 Sep 18 2014 /usr/include/libunrar.backup.0002 -> libunrar5 lrwxrwxrwx 1 root root 9 Nov 1 2014 /usr/include/libunrar.backup.0003 -> libunrar5 lrwxrwxrwx 1 root root 9 Dec 4 2014 /usr/include/libunrar.backup.0004 -> libunrar5 lrwxrwxrwx 1 root root 9 Feb 27 08:46 /usr/include/libunrar.backup.0005 -> libunrar5 lrwxrwxrwx 1 root root 9 Apr 28 07:37 /usr/include/libunrar.backup.0006 -> libunrar5 lrwxrwxrwx 1 root root 24 Jul 22 15:13 /usr/include/memenv.h -> leveldb/helpers/memenv.h lrwxrwxrwx 1 root root 8 Apr 22 01:08 /usr/include/ncurses.h -> curses.h lrwxrwxrwx 1 root root 63 May 28 16:32 /usr/include/objalloc.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/objalloc.h lrwxrwxrwx 1 root root 23 May 6 03:09 /usr/include/openjpeg.h -> openjpeg-1.5/openjpeg.h lrwxrwxrwx 1 root root 65 May 28 16:32 /usr/include/plugin-api.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/plugin-api.h lrwxrwxrwx 1 root root 18 Apr 21 18:31 /usr/include/pngconf.h -> libpng16/pngconf.h lrwxrwxrwx 1 root root 14 Apr 21 18:31 /usr/include/png.h -> libpng16/png.h lrwxrwxrwx 1 root root 21 Apr 21 18:31 /usr/include/pnglibconf.h -> libpng16/pnglibconf.h lrwxrwxrwx 1 root root 6 Jul 21 12:23 /usr/include/scsilib -> schily lrwxrwxrwx 1 root root 65 May 28 16:32 /usr/include/splay-tree.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/splay-tree.h lrwxrwxrwx 1 root root 61 May 28 16:32 /usr/include/symcat.h -> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25/include/symcat.h So yes, keep calling those a diva who probably did Gentoo when you were still in Kindergarten and who don't take your crappy allegations.
(In reply to PetaMem R&D from comment #1) > Problem solved (for me and the rude way): > > # cd /usr/include > > # ln -s leveldb/helpers/memenv.h > > > Which will leave us with a memenv.h in /usr/include instead of it just > sitting in /usr/include/leveldb/helpers > > Someone might want to fix the litecoin-qt sources there. Yep. They moved the header from <memenv.h> to <leveldb/helpers/memenv.h>. I am not familiar with leveldb's api so I don't know why they did this and can't comment on whether having the sym link there is a good idea or not. My gut reaction is that its not and the litecoin people should add a check for the version of leveldb available in configure.ac and act accordingly. I guess I could write a patch but I'm not that interested in this (sorry). What I can do is just add a blocker in the ebuild for now and alert upstream, but I bet they know already. (In reply to Rafał Mużyło from comment #2) > @comment 1: > > Given the quality of your "fix" I'd strongly suspect that one of your > previous "fixes" has just bitten you. > > Anyway, attach full build log and config.log. 1) Please take the drama elsewhere. It just adds noise. We're here to fix a bug. Period. 2) PetaMem's comment #1 makes clear at least one problem. I'm not sure about the tag YASM issue but if it disappears after adding the sym link, its probably a result of not finding <memenv.h>. I'm not sure a full build log would be that useful.
> setting that link wasn't the first action ..and you can tell this from the "report"...exactly how ? > it was also not a random symlink at a semi-random location > it is deliberately chosen after analysis and litecoin-qt compilation immediately worked That <a semi-random action> fixes <a random build issue> says exactly nothing about it being the (or even a) *proper* solution. Again, without the build log, you rarely can tell, especially that with - for example - parallel make sometimes even a large tail snippet might not suffice. > criticizing that action... Reading a few "How to (not) report bugs" documents floating around is recommended. > Having used Gentoo since sometime around 2007,... ...so, we're playing the number games now... I could start with "Having used Gentoo since at least 2005-08-01", but in the end such number is meaningless - it doesn't matter how long you've been learning, but how much did you learn. > That being said, equery reveals that leveldb package brings the memenv.h file > in some weird location. My bet would be that the problem is not > on litecoin-qt side but on leveldb site. Now, if your "report" included this short snippet from the very start, we wouldn't be having this somewhat pointless conversation... ...and I've already said, that this change in leveldb ebuild is the most likely cause. > a diva who probably did Gentoo when you were still in Kindergarten You know, I could have been there to take you back home...
(In reply to Anthony Basile from comment #6) > Yep. They moved the header from <memenv.h> to <leveldb/helpers/memenv.h>. > I am not familiar with leveldb's api so I don't know why they did this and > can't comment on whether having the sym link there is a good idea or not. > Well, as you should see in the ebuild, system leveldb patch is a Gentoo one (well, that or it's adopted from a different distro) - upstream just uses embedded. As for "symlink or not" - putting a symlink makes moving that header bit pointless - pardon the pun, it's a coin toss, depending on how many packages use the Debian location.
Was going to look at patching but after reading through all the options, seems they all have had due consideration. This package never had proxy-maint involvement. Pulling from CC
*** Bug 556322 has been marked as a duplicate of this bug. ***
*** Bug 558266 has been marked as a duplicate of this bug. ***
I'm hard depending on <=dev-libs/leveldb-1.15.0-r1. This may conflict with other pkgs needing leveldb-1.18 but I don't know of any. Hopefully upstream litecoin will catch up.
Restricting version to 1.15 breaks compatibility with virtual/bitcoin-leveldb-0:0/0::bitcoin and dev-qt/qtwebkit-5.4.2:5/5::gentoo.
By the way, I've got both net-p2p/litecoin-qt-0.10.2.2::gentoo and dev-libs/leveldb-1.18-r1:0/0::gentoo installed on my machine at the same time. Is it possible to place the version restriction on build time only?
(In reply to Pastafarianist from comment #13) > Restricting version to 1.15 breaks compatibility with > virtual/bitcoin-leveldb-0:0/0::bitcoin and dev-qt/qtwebkit-5.4.2:5/5::gentoo. I was afraid of something like that. (In reply to Pastafarianist from comment #14) > By the way, I've got both net-p2p/litecoin-qt-0.10.2.2::gentoo and > dev-libs/leveldb-1.18-r1:0/0::gentoo installed on my machine at the same > time. Is it possible to place the version restriction on build time only? Not really, I should patch the code and aim at the new location of memenv.h. Its probably a trivial patch but this is low on my priority list.
(In reply to Anthony Basile from comment #15) > (In reply to Pastafarianist from comment #13) > > Restricting version to 1.15 breaks compatibility with > > virtual/bitcoin-leveldb-0:0/0::bitcoin and dev-qt/qtwebkit-5.4.2:5/5::gentoo. > > I was afraid of something like that. > > (In reply to Pastafarianist from comment #14) > > By the way, I've got both net-p2p/litecoin-qt-0.10.2.2::gentoo and > > dev-libs/leveldb-1.18-r1:0/0::gentoo installed on my machine at the same > > time. Is it possible to place the version restriction on build time only? > > Not really, I should patch the code and aim at the new location of memenv.h. > Its probably a trivial patch but this is low on my priority list. can you please test litecoind-0.10.2.2-r2 and litecoin-qt-0.10.2.2-r1. I did hard code the version of leveldb because the way my patch works, it expects to find memenv.h at the new location and the older versions of leveldb listed i virtual/bitcoin-leveldb-0 would break it.
(In reply to Anthony Basile from comment #16) > (In reply to Anthony Basile from comment #15) > > (In reply to Pastafarianist from comment #13) > > > Restricting version to 1.15 breaks compatibility with > > > virtual/bitcoin-leveldb-0:0/0::bitcoin and dev-qt/qtwebkit-5.4.2:5/5::gentoo. > > > > I was afraid of something like that. > > > > (In reply to Pastafarianist from comment #14) > > > By the way, I've got both net-p2p/litecoin-qt-0.10.2.2::gentoo and > > > dev-libs/leveldb-1.18-r1:0/0::gentoo installed on my machine at the same > > > time. Is it possible to place the version restriction on build time only? > > > > Not really, I should patch the code and aim at the new location of memenv.h. > > Its probably a trivial patch but this is low on my priority list. > > can you please test litecoind-0.10.2.2-r2 and litecoin-qt-0.10.2.2-r1. I > did hard code the version of leveldb because the way my patch works, it > expects to find memenv.h at the new location and the older versions of > leveldb listed i virtual/bitcoin-leveldb-0 would break it. Okay I'm a little uneasy about this because leveldb didn't just change the location of memenv.h but also abi which means that litecoind-0.10.2.2 may misbehave, but let's see. reopen this bug if something breaks.
