This happens on SPARC64. .. checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/var/tmp/portag e/net-libs/webkit-gtk-1.2.6/work/webkit-1.2.6': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/net-libs/webkit-gtk-1.2.6/work/webkit-1.2.6/config.log * ERROR: net-libs/webkit-gtk-1.2.6 failed: * econf failed * * Call stack: * ebuild.sh, line 56: Called src_configure * environment, line 3270: Called econf '--disable-introspection' ' --disable-web_sockets' '--disable-coverage' '--disable-debug' '--enable-video' ' --disable-introspection' '--enable-jit' * ebuild.sh, line 552: Called die * The specific snippet of code: * e--(88%) die "econf failed" * * If you need support, post the output of 'emerge --info =net-libs/we bkit-gtk-1.2.6', * the complete build log and the output of 'emerge -pqv =net-libs/web kit-gtk-1.2.6'. * The complete build log is located at '/var/tmp/portage/net-libs/web kit-gtk-1.2.6/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-lib s/webkit-gtk-1.2.6/temp/environment'. * S: '/var/tmp/portage/net-libs/webkit-gtk-1.2.6/work/webkit-1.2.6' Logs attached
Created attachment 259705 [details] emerge --info =net-libs/we bkit-gtk-1.2.6
Created attachment 259706 [details] emerge -pqv =net-libs/webkit-gtk-1.2.6
Created attachment 259708 [details] var/tmp/portage/net-libs/web kit-gtk-1.2.6/temp/build.log
Created attachment 259710 [details] /var/tmp/portage/net-libs/webkit-gtk-1.2.6/temp/environment
Created attachment 259712 [details] config.log
IMhO the real problem is that the ebuild strips the custom CFLAGS that I use, i.e it strips out -mcpu=ultrasparc3 (which is correct and works without problems w/ a lot of packages) but doesn't strip out -mvis (multimedia extensions), which means it fails to configure when it fails to assembles a test program as it defaults to sparclite and -mvis is known not to work with that. webkit-gtk 1.2.5 built just fine with the same CFLAGS.
(In reply to comment #6) > webkit-gtk 1.2.5 built just fine with the same CFLAGS. > that's weird, 1.2.5 has the same filtering for sparc. Could you try changing to ebuild and drop the cflags filtering and see if the resulting lib works fine ? I see no bug reference with this hack in the ebuild and I'd like to drop it if possible.
The filtering was added by armin76 long ago here: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-libs/webkit-gtk/webkit-gtk-1.1.15.2.ebuild?hideattic=0&r1=1.2&r2=1.3 With a commit message of: "Add patch from Debian to fix unaligned accesses, with permission from remi, bug #292940" So I think the sparc team should chase this down as a follow-up to bug 292940.
(In reply to comment #8) > The filtering was added by armin76 long ago here: > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-libs/webkit-gtk/webkit-gtk-1.1.15.2.ebuild?hideattic=0&r1=1.2&r2=1.3 > > With a commit message of: > > "Add patch from Debian to fix unaligned accesses, with permission from remi, > bug #292940" > > So I think the sparc team should chase this down as a follow-up to bug 292940. I'm going to remove the CFLAGS filtering and see what happens.
with -mpcu=ultrasparc3 -mvis, it passed tests until an assert was thrown and consequently failed. Trying without -mvis now.
Still fails in the same place with -mcpu=ultrasparc3, so I'm fairly certain that one along with -mvis needs stripping if it is included. Rerunning tests again w/o those -m flags.
Still fails in the same place. This must be a new bug, but I'm re-testing 1.2.5 right now w/ tests.
Can you believe it, even without those CFLAGS, webkit-gtk 1.2.5 still won't configure? I'm not even using those CFLAGS! Attaching the logs.
Tracked it down to a typo in -mpcu. Rerunning tests again with 1.2.5 w/o -mvis or -ultrasparc3 to get a baseline on this as we know webkit-gtk 1.2.5 is stable.
webkit-gtk 1.2.5 still passes its tests until it fails, and that was made stable, see bug 281819. I say get rid of the filter for CFLAGS and just build it. It turns out that it does run through its tests until it fails one, same way as webkit-gtk 1.2.5. I think the test failures should be passed to upstream. I will also test it with apps after installation.
Tested it with epiphany, it would crash a lot browsing ;) I've now made the change to the 1.2.6 ebuild: # Sigbuses on SPARC with mcpu use sparc && filter-flags "-mcpu=*" "-mvis" "-mtune=*" That should filter out the -mvis CFLAG and render webkit-gtk totally safe for people using that flag!
(In reply to comment #16) > Tested it with epiphany, it would crash a lot browsing ;) > > I've now made the change to the 1.2.6 ebuild: > > # Sigbuses on SPARC with mcpu > use sparc && filter-flags "-mcpu=*" "-mvis" "-mtune=*" > > That should filter out the -mvis CFLAG and render webkit-gtk totally safe for > people using that flag! > Nice, thanks a lot for your work, is this bug solved now then?
I'm running a build without tests now, once that's done, it'll be a short test browsing with epiphany.
Good news, webkit-gtk 1.2.6 works just fine with epiphany, no crashes. I recommend that "-mvis" be added to the ebuild to be filtered out, just in case others have this as their CFLAGS/CXXFLAGS. I consider this bug now closed.
Could you please summarize the changes you needed to apply to the ebuild to let it work ok? That way we could commit them ;-) Thanks
Created attachment 259824 [details, diff] webkit-gtk-1.2.6.ebuild patch
It's quite simple, the patch simply adds '-mvis' to the list of CFLAGS/CXXFLAGS to be filtered out. As this is unstable, I think you can just patch it and commit to the portage tree for further testing before it goes stable.
+ 15 Jan 2011; Pacho Ramos <pacho@gentoo.org> -webkit-gtk-1.2.3.ebuild, + webkit-gtk-1.2.6.ebuild: + Filter -mvis on sparc due bug #351561, thanks to Alex Buell. Remove old.
