I created a fresh crossdev environment, same arch, and tried to install some packages into it. Everything installed normally except dev-python/cryptography-43.0.0, the ebuild failed with "unable to find openssl include path". I looked at the cargo crate for openssl and found the OPENSSL_DIR environment variable, adding "export OPENSSL_DIR=${ROOT}/usr" to the ebuild in the python_configure_all() stage allowed it to build successfully on the host and crossdev environment. Both the host and crossdev environment are x86_64 linux gnu using gcc, the profile on the host is default/linux/amd64/23.0/hardened and in the crossdev default/linux/amd64/23.0/split-usr/hardened (for some reason merge-usr doesn't work and keeps getting reset after running the merge-usr script). Both are using the latest gentoo repo from today. I don't really know if this is a bug or I did something wrong. Anyways I don't know if my solution is the most elegant but I didn't know any better way to make it work. I am happy to provide any additional logs, also I am doing all of this inside containers if that changes anything.
Can you include the build.log and ${CHOST}-emerge --info when it fails please? Thanks.
Info below, for the build log, I deleted the container so I'll send that in 30 min or so. Portage 3.0.65 (python 3.12.3-final-0, default/linux/amd64/23.0/split-usr/no-multilib/hardened, gcc-13, unavailable, 6.10.8-gentoo-x86_64 x86_64) Timestamp of repository gentoo: Sun, 08 Sep 2024 16:30:00 +0000 Head commit of repository gentoo: 3bd1e6425d2499b432fcc7db19a2e7accb3e2c8f sh bash 5.2_p26-r6 ld GNU ld (Gentoo 2.42 p3) 2.42.0 Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 volatile: False sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 3 sync-rsync-verify-metamanifest: yes sync-rsync-extra-opts: ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=x86-64-v2 -O2 -pipe" CHOST="x86_64-epic-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf" CXXFLAGS="-march=x86-64-v2 -O2 -pipe" DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-march=x86-64-v2 -O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync merge-wait multilib-strict network-sandbox news nodoc noinfo noman parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-march=x86-64-v2 -O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="C.UTF8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs" LEX="flex" MAKEOPTS="-j32 -l32" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/usr/x86_64-epic-linux-gnu/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl amd64 bash-completion bzip2 cet crypt gdbm hardened iconv ipv6 libtirpc ncurses nls openmp pam pcre pic pie readline seccomp split-usr ssl ssp test-rust unicode xattr xtpax zlib" ABI_X86="64" ADA_TARGET="gcc_12" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 ntrip navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" GUILE_SINGLE_TARGET="3-0" GUILE_TARGETS="3-0" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-2" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_12" PYTHON_TARGETS="python3_12" RUBY_TARGETS="ruby31 ruby32" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RANLIB, READELF, RUSTFLAGS, SHELL, SIZE, STRINGS, STRIP, YACC, YFLAGS
Build log paste https://pastebin.com/8yTMihSv
Just realized, that build log is another issue I forgot about, portage doesn't pull dev-python/cffi as a dependency for dev-python/cryptography, well not exactly, dev-python/cffi needs to be installed in the host system rather than the cross dev to get the next error. Build log of the issue I described earlier is below. https://pastebin.com/msZSGnVR Honestly, cryptography is such a borked package, theres actually another bug I know of with it and ceph that I need to make a separate bug report for.
Could you attach them instead please? pastebins expire and aren't always accessible behind firewalls
Created attachment 902550 [details] Build log with cffi import error
Created attachment 902551 [details] Build log with openssl not found error
Sure, just attached them, sorry about that. Honestly, love rust but why did they add it to python :(
I've reproduced this and looked into it. I haven't figured it out yet, but I feel like it should just work. It uses the pkg-config-rs crate, which actually isn't that dumb, but something is still off.
Got it. It works if you remove this line from /usr/bin/cross-pkg-config. > unset PKG_CONFIG_ALLOW_SYSTEM_CFLAGS pkg-config-rs allows crates to enable or disable this, but it is enabled by default. The result of "pkg-config --cflags openssl" is used to populate DEP_OPENSSL_INCLUDE. This format of this variable name is defined by Cargo, but I guess the variable itself is set by pkg-config-rs in this case. cryptography-cffi/build.rs checks whether it is set and bails if it's not. > std::env::var_os("DEP_OPENSSL_INCLUDE").expect("unable to find openssl include path"); The problem is that with PKG_CONFIG_ALLOW_SYSTEM_CFLAGS unset, the pkg-config call will return nothing because the toolchain find the headers without help. Removing that line results in DEP_OPENSSL_INCLUDE being set to -I/usr/${CHOST}/usr/include and then it works. I need to dig a little deeper to find out why DEP_OPENSSL_INCLUDE is seemingly unset as opposed to just being blank. So what do we do about this? I'm not sure. On the one hand, cryptography probably doesn't need this set. On the other hand, it is Gentoo that is explicitly preventing this from working. Why? That line has been in cross-pkg-config since forever. It's supposed to guard against bad distributions from setting the variable appropriately, which might lead to problems, but it was written with the idea that non-Gentoo distributions would use crossdev. They don't. This is not a variable that Gentoo sets anywhere that I know of. In most cases, it probably wouldn't break anything anyway. So just removing this line might be the answer. Alternatively, if pkg-config-rs is unsetting DEP_OPENSSL_INCLUDE rather than allowing it to be blank, we could possibly change that, but upstream may not accept it. Doubly so if it is Cargo that is unsetting it.
(In reply to James Le Cuirot from comment #10) > Got it. It works if you remove this line from /usr/bin/cross-pkg-config. > > > unset PKG_CONFIG_ALLOW_SYSTEM_CFLAGS > > pkg-config-rs allows crates to enable or disable this, but it is enabled by > default. The result of "pkg-config --cflags openssl" is used to populate > DEP_OPENSSL_INCLUDE. This format of this variable name is defined by Cargo, > but I guess the variable itself is set by pkg-config-rs in this case. > cryptography-cffi/build.rs checks whether it is set and bails if it's not. > > > std::env::var_os("DEP_OPENSSL_INCLUDE").expect("unable to find openssl include path"); > > The problem is that with PKG_CONFIG_ALLOW_SYSTEM_CFLAGS unset, the > pkg-config call will return nothing because the toolchain find the headers > without help. Removing that line results in DEP_OPENSSL_INCLUDE being set to > -I/usr/${CHOST}/usr/include and then it works. > > I need to dig a little deeper to find out why DEP_OPENSSL_INCLUDE is > seemingly unset as opposed to just being blank. > > So what do we do about this? I'm not sure. On the one hand, cryptography > probably doesn't need this set. On the other hand, it is Gentoo that is > explicitly preventing this from working. Why? That line has been in > cross-pkg-config since forever. It's supposed to guard against bad > distributions from setting the variable appropriately, which might lead to > problems, but it was written with the idea that non-Gentoo distributions > would use crossdev. They don't. This is not a variable that Gentoo sets > anywhere that I know of. In most cases, it probably wouldn't break anything > anyway. So just removing this line might be the answer. > > Alternatively, if pkg-config-rs is unsetting DEP_OPENSSL_INCLUDE rather than > allowing it to be blank, we could possibly change that, but upstream may not > accept it. Doubly so if it is Cargo that is unsetting it. Thank you so much for your detailed response, Y'all are geniuses at this. I will try building my crossdev with this variable unset and see if it causes any issues however, I don't have many rust packages there probably less than 5 so I doubt it will be a good test to see if it causes any issues.
No problem! I expect most Rust packages will be fine. I've cross-compiled quite a few myself, having initially added that support. On closer inspection, I found there was a little more going on here. pkg-config-rs doesn't set DEP_OPENSSL_INCLUDE itself. In this case, the openssl-sys crate uses pkg-config-rs in its build script and passes each include path to Cargo separately using cargo:include=PATH. Cargo then uses this to set DEP_OPENSSL_INCLUDE. Because the output from pkg-config is split and passed to Cargo separately, nothing at all gets passed if no output is returned. This answers my earlier blank vs unset question. It's not clear to me whether DEP_OPENSSL_INCLUDE can end up with multiple paths or not. If it can, then you have to wonder what the point of splitting them is. Curiously, it doesn't use pkg-config to find the name of the libraries or their paths. It simply looks for libssl and libcrypto in the standard toolchain locations unless you override these with OPENSSL_LIBS and/or OPENSSL_LIB_DIR. The libraries and their paths are passed to Cargo using cargo:rustc-link-lib and cargo:rustc-link-search=native, but there doesn't seem to be any corresponding DEP_* environment variables for these. pkg-config-rs can alternatively be used with Cargo via the system-deps crate, where you specify details in Cargo.toml rather than a build script, but openssl-sys doesn't take this approach "for annoying reasons". Given how this all works, I don't think there's any change we can suggest to upstream. Our only option seems to be removing that line, and probably the corresponding LIBS line too. I'll test for any fallout from that soon.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=a1f5ed5e8f866cd904e439b3792ac7505895f7f3 commit a1f5ed5e8f866cd904e439b3792ac7505895f7f3 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-09-21 21:35:27 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-09-21 21:48:40 +0000 cross-pkg-config: Don't unset PKG_CONFIG_ALLOW_SYSTEM_CFLAGS/LIBS These variables control whether pkg-config returns flags to search directories that the toolchain would search by default anyway. Rust's pkg-config-rs enables them by default, and some crates expect flags to always be returned, even if they are technically unnecessary. Unsetting these variables in the wrapper therefore breaks some crates. Having seen how this works in detail, it would be fruitless to ask upstream to change it. These lines were originally added at a time when we expected other non-Gentoo-based distributions to use crossdev. That didn't happen. Gentoo itself doesn't set these variables anywhere that I can see. Even if they were set, they are unlikely to break anything in practise now that our cross builds are better behaved than they used to be. Bug: https://bugs.gentoo.org/939334 Signed-off-by: James Le Cuirot <chewi@gentoo.org> wrappers/cross-pkg-config | 2 -- 1 file changed, 2 deletions(-)
Fix now in crossdev master. Just needs a release.
Now fixed in crossdev 20240921.
