Subject: Re: multiple versions of openssl?
To: Jeremy C. Reed <email@example.com>
From: Hal Snyder <firstname.lastname@example.org>
Date: 02/24/2004 10:13:45
"Jeremy C. Reed" <email@example.com> writes:
> On Thu, 29 Jan 2004, Hal Snyder wrote:
>> As noted in a previous posting, the latest release of Erlang, R9C-0
>> for which there is a netbsd package (thanks). But for crypto, this
>> release wants openssl-0.9.7a, per
>> http://www.erlang.org/doc/r9c/doc/highlights.html -
> This doesn't mention if it uses some API that is not compatible with
> older version. Does old version work?
I believe the package builds on i386 solaris but does not find a
compatible openssl in configure stage when the older openssl is
installed. You get a usable Erlang run-time, minus crypto.
> I don't know erlang, but I see our package already uses openssl. Is
> it broken?
I suspect w.r.t openssl that it is.
>> and netbsd pgksrc offers openssl-0.9.6l as of the 2004-1-5 Makefile.
> By the way, I think jschauma said he had a 0.9.7x already packaged
> and available but he did the update in pkgsrc for 0.9.6 instead.
Well, NetBSD has openssl 0.9.7c in /usr/bin - but this is not found on
> I recall reading a message from about this, but can't find it.
>> What is the recommended pkgsrc Makefile approach to get a
>> coexisting alternate version, say in /usr/pkg/openssl-0.9.c/.. ?
> There is not a pkgsrc way now. They would have conflicting files.
pkgviews? (just getting up to speed on buildlink - pkgviews is next)
NetBSD supports coexisting versions with gcc, doesn't it?
We run servers 24x7 and occasionally need to deploy programs depending
on a newer version of a lib (openssl, freetds, etc.) without breaking
services already running.
>> Or is there a better way?
> Try old version. And if doesn't work, either patch erlang or send-pr so
> openssl gets updated.
Working on it.
We're continuing with pkgsrc and Erlang, but for the time being have
hammered together an i386 solaris pkgsrc binary package linking an
out-of-tree openssl (in /usr/local/openssl-0.9.7b). This is a
temporary work-around; I'm still very much interested in a better fix
as understanding of pkgsrc improves.
BTW, the Erlang package should have its own buildlink[2?|3?] file.
1. Some other programs, such as yaws, need C headers it exports.
2. Erlang programs will need to find Erlang headers (*.hrl) and
application files (*.app) in order to build .boot and .script files
within a pkgsrc setting.
Will send one in when we get there, if no one else beats me to it.