Created attachment 550954 [details] build.log libtool: link: powerpc64-unknown-linux-gnu-gcc -O2 -mcpu=powerpc64 -maltivec -mabi=altivec -pipe -maltivec -fpie -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -fPIC -DPIC -pie -rdynamic -o bin/eolian/.libs/eolian_gen bin/eolian/bin_eolian_eolian_gen-main.o bin/eolian/bin_eolian_eolian_gen-types.o bin/eolian/bin_eolian_eolian_gen-headers.o bin/eolian/bin_eolian_eolian_gen-sources.o bin/eolian/bin_eolian_eolian_gen-docs.o -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries lib/eina/.libs/libeina.so -L/lib64 lib/eolian/.libs/libeolian.so /var/tmp/portage/dev-libs/efl-1.21.1/work/efl-1.21.1/src/lib/eina/.libs/libeina.so -lsystemd -lm -ldl -lrt -lpthread lib/eina/.libs/libeina.so: undefined reference to `_Uppc64_init_local' lib/eina/.libs/libeina.so: undefined reference to `_Uppc64_get_reg' lib/eina/.libs/libeina.so: undefined reference to `_Uppc64_step' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:28182: bin/eolian/eolian_gen] Error 1 make[1]: *** [Makefile:3014: all-recursive] Error 1 make: *** [Makefile:2101: all] Error 2 * ERROR: dev-libs/efl-1.21.1::gentoo failed (compile phase):
Created attachment 550956 [details] emerge --info
So, this is similar to https://bugs.gentoo.org/657750 Still have no ideas, or access to a ppc32 / ppc64 machine. Sorry. One long-shot is that if you are upgrading efl, remove the existing version first fully and make a clean new emerge. But I doubt that's the case in here.
(In reply to Joonas Niilola from comment #2) > So, this is similar to > https://bugs.gentoo.org/657750 > > Still have no ideas, or access to a ppc32 / ppc64 machine. Sorry. > > One long-shot is that if you are upgrading efl, remove the existing version > first fully and make a clean new emerge. But I doubt that's the case in here. No need to apologize in the first place and thanks for looking into this! You are right it looks exactly like 657750 I filed (missed that, oops!), which has been a 32bit build. I should probably try building from git-master and take this upstream and will do so the next few days.
Hmm, interesting... Just tried building efl-1.21.1 directly from source (./configure --enable-lua-old --disable-physics && make -j28), which succeeded! Building from source uses: CFLAGS........: -g -O2 -maltivec -fpie CXXFLAGS......: -Wno-shadow -fPIC -DPIC LDFLAGS.......: -fPIC -DPIC -pie -rdynamic But even when maching these FLAGS, the build via emerge fails, whereas building from source succeeds when configured with the same options as the Gentoo emerge: ./configure --disable-dependency-tracking --disable-silent-rules --enable-cserve --enable-image-loader-generic --enable-image-loader-jpeg --enable-image-loader-png --enable-libeeze --enable-libmount --enable-xinput22 --disable-doc --disable-eglfs --disable-gesture --disable-gstreamer --disable-image-loader-tgv --disable-tizen --disable-wayland-ivi-shell --disable-avahi --enable-image-loader-bmp --enable-image-loader-wbmp --disable-image-loader-dds --disable-drm --disable-elput --enable-image-loader-eet --disable-egl --disable-always-build-examples --disable-fb --enable-fontconfig --disable-fribidi --enable-image-loader-gif --enable-gstreamer1 --disable-harfbuzz --disable-hyphen --enable-image-loader-ico --disable-ibus --disable-image-loader-jp2k --disable-libuv --enable-lua-old --disable-neon --enable-nls --enable-poppler --disable-physics --disable-spectre --enable-image-loader-pmaps --enable-image-loader-psd --enable-pulseaudio --disable-libraw --disable-scim --disable-sdl --enable-audio --enable-static --enable-librsvg --enable-liblz4 --enable-systemd --disable-image-loader-tga --enable-image-loader-tiff --disable-tslib --disable-v4l2 --enable-valgrind --disable-libvlc --disable-vnc-server --disable-wayland --disable-image-loader-webp --disable-xcf --disable-xim --disable-xine --disable-image-loader-xpm --disable-xpresent --with-crypto=openssl --with-glib=no --with-js=none --with-net-control=none --with-profile=release --with-x11=xlib --with-x --with-opengl=full Which leaves me a bit clueless now...
That's an interesting find, indeed! Could you attach the whole ./configure output from efl's source? By the way, your make.conf has MAKEOPTS="-j29" and not -j28, but I doubt that's the problem here (since I've seen efl being compiled with -j128). The error seems to happen in linking, what if you remove "-l28" from your make.conf?
Created attachment 551570 [details] config.log (source build) Changed MAKEOPTS="-j29 -l28" to MAKEOPTS="-j1" in /etc/portage/make.conf, but it didn't make a difference.
Tried looking at differences for a while. Overall the configure outputs are different, I dont know whether emerge output hides core test phase, or if its disabled? You could try adding '--with-tests=none' to your manual configure too. I saw that with manual configure, it finds your unwind, but with emerge, it doesn't (even though it's enabled). I doubt that's the reason, but unwind is connected to libeina. Third thing you could try is emerge with FEATURES="" (or by manually disabling all features). I'll continue trying to find more differences tomorrow, but gotta go now. Thanks for being active on this :)
Created attachment 551886 [details] config.log (source build --with-tests=none)
Created attachment 551888 [details] build.log (without FEATURES)
Thanks. I don't see anything weird there. Maybe we need the log from compilation after all, could you provide the whole compile log from manual compilation? It's going to be huge and probably needs to be gzipped too, but it should show whats happening in that part where it fails with emerge. I think the syntax is something like ./configure >> ./buildlog.txt 2>&1, then make >> ./buildlog.txt 2>&1 and make install >> ./buildlog.txt 2>&1. Not sure if '&&' works here, but at least this way we get all the logs. Sorry it's taking this long, but I can't seem to find 'it'.
Created attachment 553816 [details] buildlog.txt.xz Took me a while, but here's the buildlog.txt you requested.
For some reason I haven't received emails from bugzilla, until last night when I straight received 20 messages at once. Sorry for the delay. So when comparing these two build.logs the OBVIOUS difference is linker that's being used. Is powerpc64-unknown-linux-gnu-gcc some sort of cross-compiler? In your working build.log it just says 'gcc' when linking. Also the LDFLAGS seem a bit different (like -mcpu and -mabi missing from successful build). I showed your original build.log to raster in #e IRC channel, and he _guessed_ toolchain is faulty in here, rather than efl itself. I'm thinking in the ebuild somehow strip C*/CPP*/LDFLAGS to basics and force "a working" linker, but as of now, I'm not exactly sure how to do it...
(In reply to Joonas Niilola from comment #12) > So when comparing these two build.logs the OBVIOUS difference is linker > that's being used. Is powerpc64-unknown-linux-gnu-gcc some sort of > cross-compiler? In your working build.log it just says 'gcc' when linking. > Also the LDFLAGS seem a bit different (like -mcpu and -mabi missing from > successful build). No, I do not even dare to cross-compile 'cause I don't want to set that stuff up. ;) This setting must come from CHOST="powerpc64-unknown-linux-gnu" in the standard PPC64 /etc/portage/make.conf. I'll upload the make.conf of my stable-partition so you can have a look at it. -mcpu= is needed on ppc/ppc64 if you want to build for a specific CPU/instruction set. On amd64/x86 this would be -march=, but there's no -march= in gcc for PowerPC. But I think I even did a build with all CFLAGS stripped from make.conf and got the same error. I could re-try just to be sure.
Created attachment 554348 [details] make.conf
Can no longer reproduce this bug on my current setup, dev-libs/efl-1.21.1-r2 just builds fine now. Also it seems it was already keyworded without mentioning in bug #664482.
Ok... I take that back, it's not ~ppc64 keyworded yet. I wrongly assumed that. ;)
Hmm, looks like I just forgot that this bug is only trigered with USE="-unwind". ;) So reopening 'cause I still hit it. Minimal working config is: USE="X egl gles unwind" Minimal non-working config is: USE="X egl gles -unwind"
Created attachment 558808 [details] build.log (1.21.1-r2, USE="X egl gles -unwind")
Created attachment 558810 [details] build.log.xz (1.21.1-r2, USE="X egl gles unwind")
Created attachment 558812 [details] config.log (1.21.1-r2, USE="X egl gles -unwind")
Created attachment 558816 [details] config.log (1.21.1-r2, USE="X egl gles unwind")
Thanks again! I'll read the logs later, but my current feeling is I'm tempted to just use.force unwind on for ppc64, then ;)
(In reply to Joonas Niilola from comment #22) > Thanks again! I'll read the logs later, but my current feeling is I'm > tempted to just use.force unwind on for ppc64, then ;) Well, why not? Just don't forget ppc then. ;)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9db93904d8cb6945f8b8e4c7e8cde25f9de469fa commit 9db93904d8cb6945f8b8e4c7e8cde25f9de469fa Author: Joonas Niilola <juippis@gmail.com> AuthorDate: 2019-01-12 19:28:47 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-04-13 12:02:56 +0000 profiles: force 'unwind' on with dev-libs/efl on ppc & ppc64 Bug: https://bugs.gentoo.org/668486 Bug: https://bugs.gentoo.org/657750 Signed-off-by: Joonas Niilola <juippis@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/10812 Signed-off-by: Michał Górny <mgorny@gentoo.org> profiles/arch/powerpc/package.use.force | 5 +++++ 1 file changed, 5 insertions(+)
