On 4/9/2015 11:14 AM, Baptiste Daroussin wrote: > On Thu, Apr 09, 2015 at 04:00:45PM +0000, Loganaden Velvindron wrote: >> On Thu, Apr 9, 2015 at 3:56 PM, Baptiste Daroussin <b...@freebsd.org> wrote: >>> On Thu, Apr 09, 2015 at 05:53:45PM +0200, Christian Weisgerber wrote: >>>> Baptiste Daroussin: >>>> >>>>> Some how you have mixed up things between base openssl and libressl, when >>>>> starting to activate libressl if you are using ports only you have to be >>>>> extra >>>>> careful, (same goes with ncurses or ports openssl) just installing those >>>>> ports >>>>> is enough to "pollute" nearly anything you build after with a dependency >>>>> on it >>>>> (well anything that does link to libssl, libcrypto) >>>> >>>> Well, yes, that's what I said. It's a bug. >>>> >>>>> If it very complicated and >>>>> error prone to cherry pick "only take base openssl here, only ports >>>>> openssl >>>>> there" the only "safe" way to solve this situation and being consistent >>>>> is to >>>>> always skip the version from base and enforce the version for ports. (the >>>>> otherway around is impossible - very complicated) >>>> >>>> And the addition of LibreSSL as a not-quite-equivalent alternative >>>> to ports OpenSSL makes this even more complicated. You can expect >>>> things coming out of OpenBSD (like new versions of net/openntpd) >>>> to require LibreSSL, because it includes a new library libtls that >>>> doesn't exist in OpenSSL. In the meantime, LibreSSL has removed >>>> some of the more horrific APIs of OpenSSL, which means some ports >>>> will not build against LibreSSL as is. Like python27. Fixes for >>>> these problems can be picked from the OpenBSD ports tree, if we >>>> want to. >>>> >>>> It's kind of hard to fix such problems if there is no clear policy >>>> how things are supposed to work in the first place. >>>> >>> >>> I'm and other are working on a policy about that: always enforce openssl >>> from >>> ports with just a flag to say I want openssl or I want libressl but not >>> both, >>> would apply to others libs that behave the same way but I have limited time >>> on >>> this any one who wants to work on that is welcome :) >> >> I think that we need to build up a team of people who are interested >> in making that happen in FreeBSD. >> >> I would be very interested to have a LibreSSL-powered FreeBSD server >> for production use at work. >> > The thing is when you start pulling the string on this then you have to handle > all the other cases, because ports binaries will end up with some rpath to > make > sure it finds in priority things from localbase, but then if it is also linked > to libarchive, ncurses, etc it will grab the localbase version as well > (depending on the shlib version of those) so doing the job for one of the lib > means doing it for all others. > > For now candidates are: > libarchive > ncurses > readline (which will have then to be linked to ports ncurses and not base > version through the magic of fake libtermcap) > openssl > libedit(?) > > for now I do have: > http://people.freebsd.org/~bapt/nobase.mk > http://people.freebsd.org/~bapt/ssl.mk > > which will make switch from USE_OPENSSL to USES=ssl > nobase.mk is for ncurses basically USES=ncurses will die and ncurses will just > become a regular LIB_DEPENDS > > When it becomes fun is that now all ports will have to really respect > LDFLAGS... > > I already found a couple of bad boys in that area. > > btw that should also solve some issues with python and its ncurses module. >
Peter has pointed out that OpenSSL has symbol versioning that we are not using. Enabling this in base may help the conflict issue here. Even if we force all ports to use ports OpenSSL we run into the problem you describe of loading in the base OpenSSL when linking some libraries. The versioning may avoid that. Of course that would only solve for 11.0/10.2/9.4 and not current releases. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
