Something was changed at least in CMake and now ports use include from /usr/local/include but links with base OpenSSL. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273909 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273534 Probably affected: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273747 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273960 (really there is a py-cryptography / lang/rust error) and probably other ports. Fast fix for CMake based ports is add: CMAKE_ARGS+= -DOPENSSL_ROOT_DIR=${OPENSSLBASE}
(In reply to Ivan Rozhuk from comment #0) There are many similar issues not only with openssl from base/ports but also with ncurses from base/ports and other libraries that exists in base and ports at the same time. Most of build systems are not aware about such duplicates. I see only one solution - make all base libraries that exist in ports private.
Created attachment 245049 [details] Add hints for CMake and rust staff to find proper SSL lib This patch add OPENSSL_DIR and OPENSSL_ROOT_DIR env var for CONFIGURE and MAKE env, to allow CMake and other build systems find proper SSL lib during configure and compilation. This fixes kodi, py-cryptography for me. Also there is possible to remove from prots tree Makefie~s setting this variaples to compact files.
(In reply to Oleh Hushchenkov from comment #1) I do not like this idea :) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273839 Linux have multilib distros and most build systems have hint to point where to look for libs.
Look good to me, I used a similar approach to fix this problem with libgit2: https://cgit.freebsd.org/ports/commit/?id=44751f5f02191e232afe5c327cad3d50382ba497
(In reply to Matthias Fechner from comment #4) I take your idea and your solution to make proper fix for kodi, but decide to extend it to all ports. ENGINESDIR - is unset by default in ports tree: # grep -rsp 'ENGINESDIR' /usr/ports/ /usr/ports/devel/libgit2/Makefile: -DOPENSSL_ENGINES_DIR=${ENGINESDIR} /usr/ports/security/gost-engine/Makefile:ENGINESDIR?= ${PREFIX}/${EDIR} /usr/ports/security/gost-engine/Makefile: -DOPENSSL_ENGINES_DIR=${ENGINESDIR} and CMake use only OPENSSL_ROOT_DIR: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html OPENSSL_DIR - from lang/rust. It also required for fix py-cryptography.
(In reply to Ivan Rozhuk from comment #3) The idea of base system is great. But what is the point to use libs like openssl from base in software from ports instead the same libs from ports? Sorry for offtopic.
(In reply to Oleh Hushchenkov from comment #6) because a port can use the openssl version that comes with FreeBSD or use another SSL implementation/version from ports. No matter what the user selects, it should be consitent of all software that is installed on the system.
(In reply to Oleh Hushchenkov from comment #6) IMHO you can find motivation inside git history of Mk/Uses/ssl.mk. Most software can be build and work with: DEFAULT_VERSIONS+=ssl=base
(In reply to Matthias Fechner from comment #7) and (In reply to Ivan Rozhuk from comment #8) I know about DEFAULT_VERSIONS+=ssl, it does not work for all ports. Previously I forced DEFAULT_VERSIONS+=ssl to openssl from base. But some software still require openssl only from ports. It ended with both openssl installed and random ports use random openssl(base/ports). So with FreeBSD 13-STABLE I switched DEFAULT_VERSIONS+=ssl to openssl from ports. But some software require openssl only from base. It ended with the same result. As example after recent switch from 13-STABLE to 14-STABLE www/srt stopped working because it linked with base openssl despite of DEFAULT_VERSIONS+=ssl setting. In both cases I can't plan system upgrades because can't predict which openssl used by ports. The same situation with ncurses. The only working solution is to remove/rebuild all ports all the time when openssl(or ncurses, etc.) in base or in ports does .so number bump. I understand, it's historical choice. Because of these issues I ask people what is the technical reason for exposing base libs, that exist in ports, to ports build system. And no one can provide technical arguments. I know it's wrong place for such a discuss. And thanks for your answers. Just tried to explain what I meant.
Created attachment 245058 [details] patch Probably this also should be added: CFLAGS+= -I${OPENSSLINC} LDFLAGS+= -L${OPENSSLLIB} this is for legacy make systems like simple make files and autotools.
Command to find ports that linked with base OpenSSL: grep -rsp 'libssl.so.111' /usr/local/ | sed -e 's|Binary file ||g' -e 's| matches||g' | xargs pkg which -oq | sort -u
(In reply to Ivan Rozhuk from comment #10) I applied attachment 245058 [details] to ports 00b6b938e86f and did same test as described in bug #273960, comment #0. But unfortunately error happened while installing lang/python39 as following. ---------------------------------------------------------------------- ===> Installing for python39-3.9.18 ===> Checking if python39 is already installed ===> Registering installation for python39-3.9.18 as automatic pkg-static: Unable to access file /usr0/freebsd/ports/work/usr/ports/lang/python39/work/stage/usr/local/lib/python3.9/lib-dynload/_elementtree.cpython-39.so:No such file or directory pkg-static: Unable to access file /usr0/freebsd/ports/work/usr/ports/lang/python39/work/stage/usr/local/lib/python3.9/lib-dynload/pyexpat.cpython-39.so:No such file or directory *** Error code 1 Stop. make[3]: stopped in /usr/ports/lang/python39 *** Error code 1 Stop. make[2]: stopped in /usr/ports/devel/py-setuptools *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/py-cffi *** Error code 1 Stop. make: stopped in /usr/ports/security/py-cryptography ----------------------------------------------------------------------
(In reply to Yasuhiro Kimura from comment #12) After removing all installed packages I tried `make test` again and this time lang/python39 is built and installed successfully. But build of lang/rust failed as following. ---------------------------------------------------------------------- command did not execute successfully: cd "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/rustc-1.72.0-src" && AR_x86_64_unknown_freebsd="ar" CARGO_INCREMENTAL="0" CARGO_PROFILE_RELEASE_DEBUG="0" CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS="false" CARGO_PROFILE_RELEASE_OVERFLOW_CHECKS="false" CARGO_TARGET_DIR="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1-tools" CARGO_TARGET_X86_64_UNKNOWN_FREEBSD_LINKER="cc" CC_x86_64_unknown_freebsd="cc" CFG_COMPILER_HOST_TRIPLE="x86_64-unknown-freebsd" CFG_RELEASE="1.72.0" CFG_RELEASE_CHANNEL="stable" CFG_RELEASE_NUM="1.72.0" CFG_VERSION="1.72.0 (5680fa18f 2023-08-23) (built from a source tarball)" CFG_VER_DATE="2023-08-23" CFG_VER_HASH="5680fa18feaa87f3ff04063800aec256c3d4b4be" CFLAGS_x86_64_unknown_freebsd="-ffunction-sections -fdata-sections -fPIC -m64 -pipe -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing" CXXFLAGS_x86_64_unknown_freebsd="-ffunction-sections -fdata-sections -fPIC -m64 -pipe -I/usr/local/include -fstack-protector-strong -fno-strict-aliasing" CXX_x86_64_unknown_freebsd="c++" DOC_RUST_LANG_ORG_CHANNEL="https://doc.rust-lang.org/1.72.0" LIBC_CHECK_CFG="1" LIBRARY_PATH="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/llvm/build/lib" LZMA_API_STATIC="1" RANLIB_x86_64_unknown_freebsd="ar s" REAL_LIBRARY_PATH_VAR="LD_LIBRARY_PATH" RUSTBUILD_NATIVE_DIR="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/native" RUSTC="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/bootstrap/debug/rustc" RUSTC_BOOTSTRAP="1" RUSTC_BREAK_ON_ICE="1" RUSTC_ERROR_METADATA_DST="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/tmp/extended-error-metadata" RUSTC_HOST_LINKER="cc" RUSTC_INSTALL_BINDIR="bin" RUSTC_LIBDIR="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1/lib" RUSTC_REAL="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1/bin/rustc" RUSTC_SNAPSHOT="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1/bin/rustc" RUSTC_SNAPSHOT_LIBDIR="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1/lib" RUSTC_STAGE="1" RUSTC_SYSROOT="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1" RUSTC_TLS_MODEL_INITIAL_EXEC="1" RUSTC_VERBOSE="2" RUSTDOC="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/bootstrap/debug/rustdoc" RUSTDOCFLAGS="--cfg=windows_raw_dylib -Csymbol-mangling-version=v0 -Zunstable-options --check-cfg=values(bootstrap) --check-cfg=values(parallel_compiler) --check-cfg=values(no_btreemap_remove_entry) --check-cfg=values(crossbeam_loom) --check-cfg=values(span_locations) --check-cfg=values(rustix_use_libc) --check-cfg=values(emulate_second_only_system) --check-cfg=values(windows_raw_dylib) --crate-version 1.72.0\t(5680fa18f\t2023-08-23)\t(built\tfrom\ta\tsource\ttarball)" RUSTDOC_REAL="/path/to/nowhere/rustdoc/not/required" RUSTFLAGS="--cfg=windows_raw_dylib -Csymbol-mangling-version=v0 -Zunstable-options --check-cfg=values(bootstrap) --check-cfg=values(parallel_compiler) --check-cfg=values(no_btreemap_remove_entry) --check-cfg=values(crossbeam_loom) --check-cfg=values(span_locations) --check-cfg=values(rustix_use_libc) --check-cfg=values(emulate_second_only_system) --check-cfg=values(windows_raw_dylib) -Zmacro-backtrace -Clink-args=-Wl,-z,origin -Clink-args=-Wl,-rpath,$ORIGIN/../lib -Zunstable-options -Csplit-debuginfo=off" RUST_TEST_THREADS="6" SYSROOT="/usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/x86_64-unknown-freebsd/stage1" __CARGO_DEFAULT_LIB_METADATA="stabletool-rustc" "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/bootstrap/bin/cargo" "build" "--target" "x86_64-unknown-freebsd" "--release" "-Zcheck-cfg=names,values,output,features" "-Zbinary-dep-depinfo" "-j" "6" "-v" "-v" "--frozen" "--manifest-path" "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/rustc-1.72.0-src/src/tools/cargo/Cargo.toml" expected success, got: exit status: 101 Traceback (most recent call last): File "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/rustc-1.72.0-src/x.py", line 50, in <module> bootstrap.main() File "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/rustc-1.72.0-src/src/bootstrap/bootstrap.py", line 1113, in main bootstrap(args) File "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/rustc-1.72.0-src/src/bootstrap/bootstrap.py", line 1088, in bootstrap run(args, env=env, verbose=build.verbose, is_bootstrap=True) File "/usr0/freebsd/ports/work/usr/ports/lang/rust/work/rustc-1.72.0-src/src/bootstrap/bootstrap.py", line 184, in run raise RuntimeError(err) RuntimeError: failed to run: /usr0/freebsd/ports/work/usr/ports/lang/rust/work/_build/bootstrap/debug/bootstrap dist --jobs=6 *** Error code 1 Stop. make[2]: stopped in /usr/ports/lang/rust *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/py-setuptools-rust *** Error code 1 Stop. make: stopped in /usr/ports/security/py-cryptography ----------------------------------------------------------------------
(In reply to Yasuhiro Kimura from comment #13) Build error of lang/rust is reproducible with following conditions. Ports tree: ports 00b6b938e86f + attachment 245058 [details] Poudriere: 3.3.7 Jail 13.2-RELEASE amd64 make.conf: Add 'DEFAULT_VERSIONS+=ssl=openssl30' Full buld log: https://people.freebsd.org/~yasu/poudriere/data/logs/bulk/132amd64-default-ssl/2023-09-21_14h00m35s/logs/rust-1.72.0.log
(In reply to Yasuhiro Kimura from comment #14) Thanks for testing! Adding: CFLAGS+= -I${OPENSSLINC} broke build. I revert prev patch to version that only manipulate with env vars. Legacy build systems should continue manipulate CFLAGS/LDFLAGS in port Makefile or some knob shold be added for that to ssl.mk.
(In reply to Ivan Rozhuk from comment #15) I tried attachment 245049 [details] and confirmed build of lang/rust finishes successfully.
This is fallout from the latest devel/pkgconf, which pushes base .pc files to the top of the detection logic, which in this situation base openssl is detected and used unconditionally. Traditionally the SSL provider has not been detected with pkg-config, which is why many other ports still do it properly but those using pkgconf are breaking. Currently in the process of filing a bug report with that upstream and will link it here.
Upstream issue filed with context. All workarounds currently in the tree should be reverted once this is fixed. In the meantime user-level workaround is to downgrade to 1.8.
(In reply to Charlie Li from comment #18) Thanks Charlie, but the link to the upstream issue does not work (maybe it is not available public), just get a 500 error.
(In reply to Matthias Fechner from comment #19) You may need to go through the front page of the gitea instance to the issue manually, but it's there. Happened to me when I loaded the create new issue page directly in a previous attempt.
(In reply to Charlie Li from comment #17) FWIW, the issue is only actually triggered by build-systems extracting the absolute paths to libraries from pkg-config (cmake and meson do that). Then, the compiler will find headers from ports (as soon as -I/usr/local/include ends up in CFLAGS), but the build system will try to link the libs from base. With meson, the only workaround I found was actually patching meson.build not to use pkg-config. I committed myself 3 workarounds and will happily revert them once this is properly resolved.
(In reply to Charlie Li from comment #18) Some ports set OPENSSL_DIR (rust?) and OPENSSL_ROOT_DIR (CMake) env vars suggested in patch. OPENSSL_CFLAGS= -I${OPENSSLINC} OPENSSL_LDFLAGS= -L${OPENSSLLIB} also widely used in make files for ports based on old build systems. From my point of view it should be moved inside ports mk files. Env vars safe to use globally. CFLAGS + LDFLAGS probably must have knob like: USES= ssl:cflags PS: good catch with pkgconf!
(In reply to Ivan Rozhuk from comment #22) > Some ports set OPENSSL_DIR (rust?) and OPENSSL_ROOT_DIR (CMake) env vars suggested > in patch. Still this is a workaround and only good for some specific cases, e.g. it won't help with meson. We certainly shouldn't add temporary hacks to the framework but instead get the root cause fixed (thanks Charlie for identifying it!). > OPENSSL_CFLAGS= -I${OPENSSLINC} > OPENSSL_LDFLAGS= -L${OPENSSLLIB} > [...] > USES= ssl:cflags I would say these shouldn't be needed in most cases, but if there's indeed a lot of duplication, it might be an idea. But: That's unrelated to this PR IMHO. Maybe count the occurances of manually set CFLAGS/LDFLAGS for USES=ssl and if it's really worth it, open a review?
2 weeks has left, fixes available, what we are waiting for?
(In reply to Ivan Rozhuk from comment #2) Maybe things have evolved since your patch but it does not fix py311-cryptography for me (I'm trying to run py311-certbot). However, the last line of the stacktrace says: RuntimeError: OpenSSL 3.0's legacy provider failed to load. This is a fatal error by default, but cryptography supports running without legacy algorithms by setting the environment variable CRYPTOGRAPHY_OPENSSL_NO_LEGACY. If you did not expect this error, you have likely made a mistake with your OpenSSL configuration. I tried setting CRYPTOGRAPHY_OPENSSL_NO_LEGACY to 1 and was indeed able to get certbot to run. So folks like me who are more interested in making this go away for the short term have a possible workaround now.
(In reply to Craig Leres from comment #25) This PR about incorrect linking with OpenSSL from base. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853 here was something about CRYPTOGRAPHY_OPENSSL_NO_LEGACY and other python specific issues. I do not heavy use python staff, but HomeAssistant works for me.
(In reply to Ivan Rozhuk from comment #26) Right. What led me here was running ldd on: /usr/local/lib/python3.11/site-packages/cryptography/hazmat/bindings/_rust.abi3.so and finding it was using libssl/libcrypto from /usr/lib even though the openssl30 port is installed.
(In reply to Ivan Rozhuk from comment #24) > 2 weeks has left, fixes available, what we are waiting for? I don't see any "fixes available", only workarounds. Your patch adds an incomplete (won't help e.g. with meson builds) workaround to the framework. As already stated, I'm opposed to cluttering the framework with workarounds for upstream issues we expect to be fixed. > This PR about incorrect linking with OpenSSL from base. No, that's just a symptom. The issue is pkgconf looking for .pc files in base first. This can affect anything offering a .pc file in base. Unfortunately, upstream's gitea instance is still giving me 500s. Maybe it should be reported on their github mirror as well? While waiting for a fix, it's IMHO fine to add workarounds to individual ports that can be reverted once the root cause is fixed.
(In reply to Felix Palmen from comment #28) > I don't see any "fixes available", only workarounds. Whole ports framework is a collection of workarounds to build and install software on FreeBSD. > Your patch adds an incomplete (won't help e.g. with meson builds) workaround to the framework. It add fixes for CMake and *have no idea how it name* rust build staff. Feel free to find way to fix it for meson. I have no issues with meson ports. > I'm opposed to cluttering the framework with workarounds for upstream issues we expect to be fixed. This change forces build systems to use proper OpenSSL lib. Right now. Not depend on some 3rd party pkgconf. There is at least 4 broken ports, some of them is libs, that mean that really broken apps is >4. I do not understand why me and all other users should wait for something that YOU call proper "fix". I waste my personal time to get that work, other peoples waste their time to find and apply patches from this bug tracker or use outdated port or have broken apps. This is totally disrespect to ports users and ugly engineering!
(In reply to Ivan Rozhuk from comment #29) > Whole ports framework is a collection of workarounds to build and install software on FreeBSD. No. > Not depend on some 3rd party pkgconf. To be fair, OpenSSL detection traditionally did not use pkg-config/pkgconf. Only more recently did some software start adopting this method to not only save a compile step, mostly checking OPENSSL_VERSION_NUMBER/LIBRESSL_VERSION_NUMBER, but also increase reliability in this area (in theory). Other software provided .pc files since the "beginning" and their consumers used this method accordingly. > I do not understand why me and all other users should wait for something that YOU call proper "fix". Because this wasn't a problem with pkgconf 1.8. Other users of pkgconf not on FreeBSD have experienced related regressions with the current version. One such user suspects that a single commit that snuck in for 2.0 (but not 1.9) may have caused this, and I'm taking a look.
> Because this wasn't a problem with pkgconf 1.8. No one care about pkgconf, we have broken ports, we have fixes for it. Is something more required to merge? Provided patches here and with linked "Blocks" fix issues RIGHT NOW: - using OFFICIAL way [1] for CMake, that already used in few ports in tree, - using OPENSSL_DIR for rust ports, this also already used in ports tree - add CFLAGS+= -I${OPENSSLINC} / LDFLAGS+= -L${OPENSSLLIB} - this is also widely used in ports tree and this change only for broken ports. All these changes switch from "auto provided by pkgconf" to "set by ports framework". 1. OPENSSL_ROOT_DIR: https://cmake.org/cmake/help/latest/module/FindOpenSSL.html
(In reply to Ivan Rozhuk from comment #31) > No one care about pkgconf, we have broken ports, we have fixes for it. Those are not fixes, they are workarounds as zirias@ mentioned. If you want to talk "ugly engineering", all of what you suggested is just that. If the workarounds are committed but then pkgconf behaves itself again, all such workarounds have to be tracked down and reverted, which are far more disruptive and ugly than just doing it right the first time. Nothing is broken when only using the base system libraries, which is the default. > - using OFFICIAL way [1] for CMake, that already used in few ports in tree, ...is also broken with the current pkgconf.
(In reply to Charlie Li from comment #32) > Those are not fixes, they are workarounds as zirias@ mentioned. As far it is widely used, you should agree with: "Whole ports framework is a collection of workarounds to build and install software on FreeBSD." ) > If you want to talk "ugly engineering", all of what you suggested is just that. Does using official CMake env var "ugly engineering" and "workarounds"? > If the workarounds are committed but then pkgconf behaves itself again, all such workarounds have to be tracked down and reverted. It is already exits in ports tree. All ports that have set these env vars *FLAGS in their make files - does not broke with pkgconf. No need to remove it in future. > is also broken with the current pkgconf. It is not true. With attached here patch multimedia/kodi build ok, without - fail. Do you both with zirias@ have tech args to not merge? Is attached brokes something? - Have you log for that? If no - step aside.
(In reply to Ivan Rozhuk from comment #33) > As far it is widely used, you should agree with: "Whole ports framework is a collection of workarounds to build and install software on FreeBSD." ) Hard no. Otherwise some of us wouldn't have a care about technical debt management, amongst other things. > Does using official CMake env var "ugly engineering" and "workarounds"? Yes. There is no need to use the additional variables unless the build process of the specific software in question, and uniquely to that software, does something weird. > It is already exits in ports tree. Only certain cases, and they happened prior to understanding the actual problem at hand. > If no - step aside. That's not for you to suggest.
(In reply to Charlie Li from comment #34) > Do you both with zirias@ have tech args to not merge? > Is attached brokes something? - Have you log for that?
(In reply to Ivan Rozhuk from comment #35) You've been explained many times. No, FreeBSD ports are NOT a collection of workarounds. Upstream bugs happen, and we apply fixes or workarounds where necessary *to individual ports*, still making sure issues will be fixed upstream. Therefore, if you want to add temporary workarounds to individual ports, feel free to suggest them, it will be the committer's responsibility to revert them once the bug in pkgconf is fixed. But the framework should only ever have helpers for typical portability issues that are NOT bugs. The attached patch will not be merged. Please stop spamming about it.
(In reply to Felix Palmen from comment #36) Is attached patch brokes something? - Have you log/evidence for that?
How long cargo cult adepts of the great upstream defaults will wait for FreeBSD workaround in pkgconf instead of google: "pkgconf multilib" or RTFM? :) https://www.freedesktop.org/wiki/Software/pkg-config/CrossCompileProposal/ +5 min for experiments: PKG_CONFIG_PATH=/usr/libdata/pkgconfig/:/usr/local/libdata/pkgconfig/
(In reply to Ivan Rozhuk from comment #38) Great, thanks for that! Also, I support the idea that adding a local workaround is fine pending an upstream fix, particularly since the bug report to pkgconf appears not to be treated with the utmost urgency over there. Waiting for security/py-cryptography to get updated to a modern, i.e. rust-using, version was enough of a pain that I am _really_ not in favor of having it broken again by a change elsewhere that has a simple workaround.
(In reply to Christian Ullrich from comment #39) You are welcome! IMHO there is misunderstanding of "workaround" vs "option/setting set". https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273961#add_comment this is list of OPTIONS that in my understanding should be set just because user set it by selecting *SSL* version. But for now user choice is ignored and using workaround/hacks (removing all other *SSL* lib except one to use SSL=base + always start lib search always from /usr/local) let pkgcong, CMake and other to find first available lib. Same with PKG_CONFIG_PATH - it is not hack, not workaround, it is just OS specific setting. Many multilib linux distro do not ask pkgconf/CMake/etc... to add distro specific defaults and just use already existing and documented options/setting to specify what/where/how find/use.
(In reply to Ivan Rozhuk from comment #40) We're not a multilib Linux distro. (In reply to Christian Ullrich from comment #39) The upstream author/maintainer currently has more pressing things to deal with that if left unabated will hamper pkgconf development even more.
Created attachment 245503 [details] v1 Revert the one offending commit. At least irc/irssi and devel/libgit2 (after removing all variables for any workarounds) detect and use the correct USES=ssl provider as in 1.8.1.
(In reply to Charlie Li from comment #42) Please do not set "obsolete: true" to other patches since you have no tech explanation.
Comment on attachment 245049 [details] Add hints for CMake and rust staff to find proper SSL lib No, this will not be considered any further. The technical explanation against this is not only because it is ultimately a workaround, but is not actually correct in the general case. Logs, like anything else with code, do not prove the absence of bugs. All this does is add more liability. This is also a stern reminder that simplicity is not easy, it is not a "five minute" walk in the park.
Created attachment 245511 [details] v2 Use the actual upstream commit, which fixes PKG_CONFIG_PATH/PKG_CONFIG_LIBDIR order processing. /usr/libdata/pkgconfig is the last element of PKG_CONFIG_LIBDIR when building with poudriere, and since the commit that made it into 2.0.0 processed these variables backwards, /usr/libdata/pkgconfig would come up first every time, leading to base OpenSSL (and others) detected and used unconditionally.
(In reply to Charlie Li from comment #44) > The technical explanation against this is not only because it is ultimately a workaround, Labeling it as "workaround" - is not "technical explanation". > but is not actually correct in the general case. You does not explain what is incorrect. > Logs, like anything else with code, do not prove the absence of bugs. Does it meat that all your words based on nothing? > All this does is add more liability. Is it tech problem?
(In reply to Ivan Rozhuk from comment #46) For one, none of this works with meson which generally tries to shy away from using environment variables. For the USES=ssl case, unless specifically commanded in the dependency() call, meson always tries pkg-config/pkgconf first to detect the library and uses the absolute paths to the libraries. .pc files are now provided for every USES=ssl case so no other detection method is ever tried, and environment variables are not honoured. This was demonstrated with the irc/irssi workaround that will have to be reverted later. All in all, this is one example of why your patch is incorrect for the general case, and thus presents additional liability on multiple fronts.
(In reply to Charlie Li from comment #47) 1. Is I understand correct that you label patch that have description: "for CMake and some rust***" as "workaround", "incorrect" only because it does not work for meson and pkgconf? 2. Why CMake and rust ports must continue rely only on pkgconf defaults? > All in all, this is one example of why your patch is incorrect for the general case, and thus presents additional liability on multiple fronts. This "example" only show that patch work as it described, you does not show what is "incorrect". I do promote it as fix for CMake and rust for all future possible pkconf defaults changes, to reduce possible harm and make easy for porters, in case that these vars will be set by ports framework, like it done for many other CMake/... build systems in ports mk files. For CMake this is +1 system specific var, you can find at least 5 of them in Mk/Uses/cmake.mk. 3. Can you show all other "examples"? 4. Is "liability" is more important that already broken ports? Is something can be worse than already broken ports? 5. What is "multiple fronts"? 6. Is any tech reason to not try add PKG_CONFIG_PATH=/usr/libdata/pkgconfig/:/usr/local/libdata/pkgconfig/ to Mk/Uses/pkgconfig.mk and test it?
Comment on attachment 245049 [details] Add hints for CMake and rust staff to find proper SSL lib There were more than enough reasons given why this patch is wrong. It doesn't do any good for anything other than cmake based builds (like specifically meson builds). It clutters env variables with no way to override it. It doubles functionality that should be provided by pkgconf (and, always was). To name just a few. Now please, stop it.
(In reply to Charlie Li from comment #45) > Use the actual upstream commit, With the current reliability issues of the gitea host, I would suggest to rather copy the patch for the commit locally in the port.
(In reply to Ivan Rozhuk from comment #48) You were seeking to modify a file that affects all port builds, so the logic has to be correct no matter the configure/build system used. If anything, more variables currently present should be considered for removal, especially as bugs and configuration issues from older iterations are addressed. We're not obligated to show any additional examples. Additionally, when one example fails, you may need to reconsider how you see the problem, perhaps starting with the failed case. Something better may come up. The whole point of pkg-config/pkgconf is a query interface that provides exactly where a specified library is located and how to link to them. If the query process goes wrong, seek to investigate and fix that rather than adding more code that has to be maintained. In this case, the location order for finding .pc files went wrong starting with pkgconf 2.0.0. We already define that specific order in bsd.port.mk as PKG_CONFIG_LIBDIR, so any additional elements and their ordering need justification. Your additional suggestion with PKG_CONFIG_PATH is even more wrong, since the order would unconditionally pick the base system library over any port, which is what we don't want and the original point of this bug. It also duplicates the existing PKG_CONFIG_LIBDIR. In all, your suggestions do not reduce possible harm or make our lives easier, quite the opposite, hence liability. (In reply to Felix Palmen from comment #50) gitea was just updated with I assume an infrastructure shore-up, and the commit itself is also on github, hence the two PATCH_SITES.
(In reply to Charlie Li from comment #51) > Your additional suggestion with PKG_CONFIG_PATH is even more wrong, > since the order would unconditionally pick the base system library > over any port, which is what we don't want and the original point > of this bug. Please refer to comment #45, authored by ... umm ... you, that points out that pkgconfig 2.0 processes path entries in reverse order. I was surprised myself when I tried Ivan's suggestion, but what he posted works as is. > It also duplicates the existing PKG_CONFIG_LIBDIR. It clearly does not, since it changes pkgconf's behavior.
(In reply to Christian Ullrich from comment #52) > that points out that pkgconfig 2.0 processes path entries in reverse order. ...which upstream, with some users' help, established as the wrong behaviour. It has since been corrected, with the commit included as a patch here. It will most likely be incorporated in the next pkgconf release. We are not going to confirm or work around the root cause especially when it has been fixed.
(In reply to Felix Palmen from comment #49) > It doesn't do any good for anything other than cmake based builds (like specifically meson builds). Yes, it is true. Same time it fix 273534, 273960 and probably more other ports. We have a lot CMake + ssl ports. If you need to fix meson why do you not test: PKG_CONFIG_PATH=/usr/libdata/pkgconfig/:/usr/local/libdata/pkgconfig/ ? > It clutters env variables with no way to override it. Why it is bad, since Mk/Uses/cmake.mk contains many "same" variables? > It doubles functionality that should be provided by pkgconf (and, always was). As my point of view it replaces it. CMake and rust use provided by user OpenSSL lib instead of something that pkgconf found. > To name just a few. Please continue.
(In reply to Charlie Li from comment #51) Can you answer to the questions one-by-one? There was 6 simple questions, please, answer using at numbers or quotes.
(In reply to Ivan Rozhuk from comment #54) > If you need to fix meson why do you not test: > PKG_CONFIG_PATH=/usr/libdata/pkgconfig/:/usr/local/libdata/pkgconfig/ ? Because this is as wrong as it can ever get, it relies on the broken behavior. Path lists are always expected to be searched from the beginning, not from the end. So this would break the instant the root cause is fixed! > Please continue. We won't play silly games here. We always welcome contributions. Contributing to a project also means listening to what reviewers have to say, and also accept rejection of individual patches -- as always, reasons were given. We won't add hacky workarounds to the framework for bugs that can and should be fixed. And now that we have the *correct* fix available (just awaiting maintainer approval), this is even more riding a dead horse, all you're doing here is spamming the PR. Please stop this.
(In reply to Felix Palmen from comment #56) > Because this is as wrong as it can ever get This is at least can be quick workaround, till upstream fix their issues. Is it very hard test and commit it now and revert commit on pkfconf update? > We won't play silly games here. You and Charlie Li use silly polemic trick: "you are wrong because 1, 2 and many/100500 other reasons". I ask to 1, 2 and ask more reasons but you both fail to ask to my ask and fail to provide more reasons/arguments/etc. You both avoiding answer to my direct questions, you just ignore it. > We always welcome contributions. Who are "we"? What contributions you wait for? There is at least 8 open tickets with LibreSSL, some of them from 2022.11 - almost year: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266817 Why you use "we", while WE (at least subscribers of this and linked) PR stick with broken ports? > Contributing to a project also means listening to what reviewers have to say, Ok, say something: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273961#c48 Please use numbers or quotes in reply. > and also accept rejection of individual patches -- as always, reasons were given. Current problem of this topic - reasons have poor motivation, no tech discussion, questions are ignored. I come here to solve my problems, I do not care will you reject or apply my path, I do care that things work again. Since you does reject my work and does not provide any other fix/workarounds/whatever/etc..., does not provide any suggestion how to improve patches - why you are here? What are you doing here? Is your real motivation here to solve issues and improve FreeBSD+++? I repeat: start fixing issues or step aside and let other do this. There is no place to infinite wait for "state of arc" fixes that you likes. And another part about waiting and responsibility. As I understand - you priority is not end users, since: "we do not care, you use non default SSL, so we will not fix". At my work our product based on FreeBSD+ports, and we had use libressl for a while. Now we switch to OpenSSL from ports and there is only one reason: poor support. But FreeBSD strikes us again - now security/py-cryptography broken. Is business users also not important for you? Or it is not important for FreeBSD project? If you do not want do anything and do not want responsibility, but for some reason want to serve FreeBSD project - why you just not rollback/downgrade pkgconf at 2023-09-26?
PS For peoples that need to build/update/work right now, here is quick fix: add to /etc/make.conf # Remove after fix: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273961 PKG_CONFIG_PATH=/usr/libdata/pkgconfig/:/usr/local/libdata/pkgconfig/ .export PKG_CONFIG_PATH I do test it with irc/hexchat (meson+pkgconf+ssl + libressl).
(In reply to Charlie Li from comment #18, 2023-09-26) > Upstream issue filed with context. … Thank you, and now noted (similarly, with thanks to upstream): <https://gitea.treehouse.systems/ariadne/pkgconf/commit/652aff97906d7eadca6fe727b16f6511d8dbfe05> (2023-10-08) > path: add pkgconf_path_prepend API for --with-path > > Otherwise, PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR elements would be > processed backwards. > > Fixes: <https://gitea.treehouse.systems/ariadne/pkgconf/commit/384ade5> > (path: prepend paths rather than append paths when processing > --with-path arguments) > Closes: <https://gitea.treehouse.systems/ariadne/pkgconf/issues/250> > Signed-off-by: Ariadne Conill <ariadne@…> In parallel (the same hash): <https://github.com/pkgconf/pkgconf/commit/652aff97906d7eadca6fe727b16f6511d8dbfe05> closed <https://github.com/pkgconf/pkgconf/issues/250>. ^Triage: * status.
*** Bug 274419 has been marked as a duplicate of this bug. ***
v2 patch works fine; if no regression reported/found, please commit asap
(In reply to Ivan Rozhuk from comment #58) Thank you ! Works for me, fixed the error "ImportError: /usr/local/lib/python3.9/site-packages/cryptography/hazmat/bindings/_rust.abi3.so: Undefined symbol "EVP_default_properties_is_fips_enabled" with py-certbot ;-)
*** Bug 274744 has been marked as a duplicate of this bug. ***
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=6ff5f81bfc266f904a6f84e794898e29f1f6a6f5 commit 6ff5f81bfc266f904a6f84e794898e29f1f6a6f5 Author: Baptiste Daroussin <bapt@FreeBSD.org> AuthorDate: 2023-11-08 13:13:49 +0000 Commit: Baptiste Daroussin <bapt@FreeBSD.org> CommitDate: 2023-11-08 13:16:59 +0000 devel/pkgconf: incorporate a patch from upstream without this patch pkgconf will process PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR backwards. PR: 273961 Reported by: rozhuk.im@gmail.com Patch by: vishwin devel/pkgconf/Makefile | 7 ++++++- devel/pkgconf/distinfo | 4 +++- 2 files changed, 9 insertions(+), 2 deletions(-)
Patch appreciated!
Thanks Baptiste Daroussin, now it works! Do not forget remove workaround from make.conf if you have it.