Apparently the package builds files but is not able to find them later. It builds fine on all my Gentoo systems, except the one that uses Gentoo-prefix. Reproducible: Always
Created attachment 861583 [details] build.log of media-gfx/graphviz-8.0.3:0 Compressed because it exceeds 1000 KB
Also reported upstream, in case they have any suggestions → https://gitlab.com/graphviz/graphviz/-/issues/2401
Created attachment 861772 [details, diff] proposed patch This error happens because the ebuild does not run configure with --with-expatlibdir, and the graphviz configure script defaults to /usr/lib64, and then adds -L/usr/lib64 to basically every link command with disastrous results. I don't know why the configure script uses hardcoded paths like this but the solution on the ebuild side seems simple: just pass an appropriate --with-expatlibdir to the configure script. As a workaround, you can use EXTRA_ECONF="--with-expatlibdir='\${libdir}'"
Created attachment 861774 [details, diff] proposed patch v2 v2 patch: - Set EXPAT_CONFIG to the absolute filename of a program that produces no output. This will prevent the configure script from finding any expat-config program from the host bin directories (if it does find such a program, the configure script will run it and possibly add more bogus compiler flags). - Using --with-expatlibdir='${libdir}' works, and is expanded properly in the makefile, but the configure script runs its link test using a literal, unexpanded '-L${libdir}'. This is a minor issue since the GNU linker just ignores -L options that refer to nonexistent directories and it picks up libexpat from the default search path. Expand this in the ebuild instead.
Created attachment 861778 [details] build log after patch proposal v2 Thank you for the patch proposal. I tried it out but sadly it didn't work :(
Try my patch from https://gitlab.com/graphviz/graphviz/-/merge_requests/3244 (that also adds -lexpat for the libcommon target). Don't forget to add an eautoreconf call in src_prepare.
Sadly that did not work, attaching the build log and some shell commands showing the userpatch and the edit to the ebuild.
Created attachment 863836 [details] build.log after upstream patch 3244 Build log after Soap's patch
Created attachment 863837 [details] debug.log after upstream patch 3244 Debug log after Soap's patch
(In reply to Horea Christian from comment #8) > Created attachment 863836 [details] > build.log after upstream patch 3244 > > Build log after Soap's patch From this log: /home/chymera/gentoo/var/tmp/portage/media-gfx/graphviz-8.0.5/temp/environment: line 2054: eautoreconf: command not found [...] Looks like you've pooched your ebuild modifications (forgot to inherit autotools?)
This is caused by https://bugs.gentoo.org/892549, not an upstream bug
(In reply to Yiyang Wu from comment #11) > This is caused by https://bugs.gentoo.org/892549, not an upstream bug As a temporary workaround, try using linker other than ld.bfd, like gold/lld/mold, by specifying something like `LDFLAGS="-fuse-ld=mold"`
The problem is that the sysroot is being prepended to the runpath entries. > [pid 16697] openat(AT_FDCWD, "/mnt/tmp/myprefix/var/tmp/portage/media-gfx/graphviz-9.0.0/work/graphviz-9.0.0/lib/xdot/.libs/libxdot.so.4", O_RDONLY) = -1 ENOENT (No such file or directory) That is very frustrating after I thought we'd finally cracked such issues. The runtime linker presumably doesn't do this. I'll look into patching binutils again.
Created attachment 873197 [details, diff] Proposed binutils patch This proposed binutils patch fixes it. Please give it a try. It checks with the sysroot (like before), then failing that, without the sysroot. Depending on the path, the sysroot may or may not be appropriate, so without making it too clever or Gentoo-specific, we have to check both. This also fixes the cross-prefix case where the path involved really is outside the sysroot. When it's inside, there is no clean solution. Maybe we can get away without fixing that case, as -L flags probably cover it, but it's hard to say for sure.
