Summary: | net-p2p/bitcoind-0.6.3 bad openssl dep | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Patrick Lauer <patrick> |
Component: | New packages | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, luke-jr+gentoobugs |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Patrick Lauer
2013-04-14 10:51:08 UTC
Looks like openssl-0.9.8x only installs two files: /usr/lib64/{libcrypto.so.0.9.8,libssl.so.0.9.8} while openssl-1.0.1c installs the whole suite. Try: USE="-* zlib" ebuild openssl-0.9.8x.ebuild clean install tree /var/tmp/portage/dev-libs/openssl-0.9.8x/image/ Only two files there. But, USE="-* zlib" ebuild openssl-1.0.1c.ebuild clean install tree /var/tmp/portage/dev-libs/openssl-1.0.1c/image/ the entire suite including the .h files. The difference is because in < 1.0.0 we have only emake -j1 build_libs while afterwards we have emake all. I can't imagine this isn't by design. I'll wait a few days in case I'm missing something here and then update the bitcoind and bitcoin-qt ebuilds accordingly. (In reply to comment #1) > Looks like openssl-0.9.8x only installs two files: > > /usr/lib64/{libcrypto.so.0.9.8,libssl.so.0.9.8} > > while openssl-1.0.1c installs the whole suite. Try: > > USE="-* zlib" ebuild openssl-0.9.8x.ebuild clean install > tree /var/tmp/portage/dev-libs/openssl-0.9.8x/image/ > > Only two files there. But, > > USE="-* zlib" ebuild openssl-1.0.1c.ebuild clean install > tree /var/tmp/portage/dev-libs/openssl-1.0.1c/image/ > > the entire suite including the .h files. > > The difference is because in < 1.0.0 we have only emake -j1 build_libs while > afterwards we have emake all. > > I can't imagine this isn't by design. I'll wait a few days in case I'm > missing something here and then update the bitcoind and bitcoin-qt ebuilds > accordingly. The 0.9.8 series is legacy now and only to be used by binary only applications that can't be compiled against the latest sources. You'll see that 0.9.8 is slotted to allow installation along side 1.0.0, which provides the headers. There for its only necessary for 0.9.8 to provide the libraries. Additionally its worth noting that as of May 15th this version (and anything below 0.8.1) will cease working correctly so you likely want to start getting some new version into the tree and stable soon. There's also a local DB upgrade that users must endure when going to 0.8.1 so you want to give them plenty of time in advance. (In reply to comment #2) > The 0.9.8 series is legacy now and only to be used by binary only > applications that can't be compiled against the latest sources. You'll see > that 0.9.8 is slotted to allow installation along side 1.0.0, which provides > the headers. There for its only necessary for 0.9.8 to provide the libraries. I've pushed a slot dependency to the overlay. > Additionally its worth noting that as of May 15th this version (and anything > below 0.8.1) will cease working correctly so you likely want to start > getting some new version into the tree and stable soon. There's also a local > DB upgrade that users must endure when going to 0.8.1 so you want to give > them plenty of time in advance. 0.6.5rc2 is May15-compatible. I'm not sure yet what version we will be targetting to stabilize. Probably 0.8.1 if Gentoo policies let us. fixed |