As per the subject, postfix fails to build with openldap as a dependancy if fetch is enabled in openldap and you use openssl from ports (10+ particularly - though I don't know why it worked in 9.x) debugging the problem I got to the point of: /usr/bin/ld: warning: libssl.so.7, needed by //usr/lib/libfetch.so.6, may conflict with libssl.so.8 /usr/bin/ld: warning: libcrypto.so.7, needed by //usr/lib/libfetch.so.6, may conflict with libcrypto.so.8 unsetting fetch support in openldap allowed postfix to build correctly.... Don't know if this is an openldap issue or postfix issue - however openldap compiled with no errors with and without fetch enabled, it was only postfix that failed to build... Oddly enough the resultant build error was: postconf: environment corrupt; missing value for BLOCKSIZ ./postconf: fatal: out of memory and then... /bin/sh postfix-install -non-interactive -package postconf: environment corrupt; missing value for readme_d bin/postconf: fatal: out of memory postconf: environment corrupt; missing value for readme_d bin/postconf: fatal: out of memory postconf: environment corrupt; missing value for readme_d bin/postconf: fatal: out of memory postconf: environment corrupt; missing value for readme_d bin/postconf: fatal: out of memory postconf: environment corrupt; missing value for readme_d bin/postconf: fatal: out of memory postfix-install: Error: "" should be an absolute path name. *** Error code 1 Changing the options for postfix to disable LDAP and it built. Changing the options back and it failed in exactly the same way. Removing Fetch from openldap and both were rebuilt successfully.
In your case slapd was build against security/openssl and libfetch against base openssl (1.0.x) and there should be the first error message thrown by openladp that mixed openssl dependency is not supported because of the openssl library version change. I suspect this worked on 9.x because there was no library version difference. With mixed libcrypto.so.X versions and both as dependency "ld"cannot decide which library should be used and fails.
Yeah got that... Where does libfetch come from? Something in BASE or from OpenSSL in BASE? Because this would point to being an openldap issue - except if there is no way to get libfetch from ports... The only other thing is why does postconf run out of memory? I was thinking the two were not related - until I did the whole switch on-switch off thing. Anyhow thanks for the thoughts - would like to get to the bottom of it.. CC'ing Xin Li to see if we can get anything else out of it...
...and just so you know - I'm parallel building on 9.3 as well as 10.0 both pkgng and old pkg_* tools ... it only fails for 10.0 pkgng using the current ports tree (rather than my own that allows pkg_* tools) Same options, same versions in both the current and my ports trees.
(In reply to Michelle Sullivan from comment #0) This is a known issue and I don't think there is any easy solution (and this is exactly why FETCH is a non-default option): The base system libfetch has to be linked against base system libssl, and one would probably don't want to use WITH_OPENSSL_BASE= when building third party ports either. Why do you enable FETCH in the first place, though? I don't think it's used in any other places (Linux don't have libfetch, for instance) and the sole usage of fetch(3) API in OpenLDAP is so that a LDIF file can reference foreign URL, and I think it's really rare -- and if this is really needed, it's probably a good idea to teach OpenLDAP code to use curl instead as a long term solution.
(In reply to Xin LI from comment #4) Ah and cURL supports OpenLDAP so it's probably a no-go to add such dependency :(
That is exactly why I use the FETCH option ;-) Though I only use it one one machine atm and that can be compiled separately... Interestingly though openldap uses openssl from either ports or base (I believe) but based on the openssl make code which determines on a global config (at least in my build envs) Perhaps defining FETCH and WITH_OPENSSL_PORT=yes should throw an error? Or is there are libfetch that can be pulled in from ports? (NetBSD has net/libfetch - FreeBSD currently doesn't have anything) and then making it a dependency of OpenLDAP if "WITH_OPENSSL_PORT=yes" is defined...? ...anyhow looks like this is not a postfix issue, but I believe the subject maybe useful for others (as i have seen messages either on IRC or the ports@ ML so feel free to drop out of the CC Olli ;-) )
Created attachment 158464 [details] [patch] stop users mixing OpenSSL base/port Perhaps the following patch will stop users trying to mix unsupported things.
(In reply to Olli Hauer from comment #7) Looks good to me (I'm not sure but should we add a CONFLICT as well?)
+1 CONFLICT seems more appropriate (IGNORE has caused me pain with poudriere - CONFLICT doesn't)
Assign to Xin LI +1 for CONFLICT or BROKEN
A commit references this bug: Author: ohauer Date: Sun Jan 10 20:46:37 UTC 2016 New revision: 405746 URL: https://svnweb.freebsd.org/changeset/ports/405746 Log: - mark broken if build with FETCH=on agains OpenSSL from ports PR: 201372 Submitted by: Michelle Sullivan Reviewed by: delphij@ Changes: head/net/openldap24-server/Makefile
I've taken the liberty to commit the proposed patch