>and "hidden" package dependencies bite the most and the hardest.
>
>I'm now rebuilding the umpteenth package that had a stealth dependency
>on the OpenSSL package on a -current machine with OpenSSL installed
>natively because of the use of "-L${PREFIX}/lib" in package builds.  I
>had encountered something at one point, probably due to a now fixed bug
>in pkgsrc, that required the OpenSSL package instead of the in-tree
>version.  I eventually cleaned up that mistake and deleted the OpenSSL
>package.  Suddenly half my packages fail with ``Shared object
>"libcrypto.so.1" not found''!  (this latest one is ethereal!)

	in general, yes that's true.  the real source of the problem is 
	that you have two set of openssl files in your system.

	the best solution i can ever think of is to remove pkg-based openssl
	when you get openssl in base tree (like upgrade to 1.5).  it is safe
	to keep pkg-based openssl for a while (until next time you compile
	new binary), but if you keep two of them longer and run compilation,
	you will be in trouble.

	there are other reasons to add -L/usr/pkg/lib -I/usr/pkg/include
	(like for ncurses), and if you have /usr/lib/libcrypto.so and
	/usr/pkg/lib/libcrypto.so, you have no idea which one will be picked.
	also, if you use /usr/pkg/include/openssl with /usr/lib/libcrypto.so,
	you will be in a BIG trouble.

itojun