Summary: | =app-emulation/virtualbox-4.1.10[vboxwebsrv] fails to build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Markos Chandras (RETIRED) <hwoarang> |
Component: | Current packages | Assignee: | Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ckonstanski, kripton, patrick, swapon, tb |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
ebuild patch
configure patch |
Description
Markos Chandras (RETIRED)
2012-03-17 10:52:50 UTC
This seems to be fixed when updating to the latest gsoap from bug #389883 No sorry, I was wrong I think the problem is that virtualbox links to libgsoap++ and not libgsoapssl which is the one containing the missing symbols Created attachment 305695 [details, diff]
ebuild patch
Created attachment 305697 [details, diff]
configure patch
Patch configure script to use libgsoapssl++ instead of libgsoap++
This patch fixes the problem for me
Compiling worked fine for me on x64 with those patches! Thanks! Worked for me, too (amd64). Please commit If anyone has an account for virtualbox bugzilla please open a bug upstream so this fix will go to future virtualbox releases. Thanks Will do so in about 30 minutes. Have to drive home first (In reply to comment #9) > Will do so in about 30 minutes. Have to drive home first Okay, I'll take that back. I had a tracker-account back in the days they were owned by Sun Microsystems. The accounts seem to have been resetted with the "move" to Oracle. They don't seem to be able to send me an email to reset my password and I don't feel like re-registering - esp. with Oracle. Anyone else with a current Oracle-login to write a bug report for upstream? Might or might not be related to https://bugs.gentoo.org/show_bug.cgi?id=340647 I could eventually push the patch upstream through their dev list (that's a common way they do it - I've been following it for quite a while). The patch would need to be licensed under MIT, though (easier than assigning copyright to them, I think)? On the other hand, has anyone else checked whether other distros have this same type of problem (i.e. is it Gentoo-specific)? (In reply to comment #11) > Might or might not be related to > https://bugs.gentoo.org/show_bug.cgi?id=340647 Similar problem but different package so not related at all if you ask me (In reply to comment #12) > I could eventually push the patch upstream through their dev list (that's a > common way they do it - I've been following it for quite a while). The patch > would need to be licensed under MIT, though (easier than assigning copyright > to them, I think)? > > On the other hand, has anyone else checked whether other distros have this > same type of problem (i.e. is it Gentoo-specific)? It does not seem Gentoo specific. We don't build gsoap in a special way. If you send this upstream, please paste the url from the list archives so we can keep track of it Any progress on sending this upstream? Ah, sorry. Got a bit distracted. Just to verify with you since you're the author of the patch - I'll submit it under MIT to them if that's ok? I'll paste a link to this bug report as well. I'll also have a small look tomorrow at some of the other distros to see how they pack the gsoap libraries as well, just to be on the safe side. So far, looking at Debian Squeeze, they have that symbol in the same library as well (logical I guess). I don't mind the license of the patch as long as it is fixed. Feel free to do whatever you want :) Well, next time I should pay more attention to the VBox dev list. They've already landed the patch in their svn: https://www.virtualbox.org/browser/vbox/trunk/configure?rev=40476 A fellow had the same issue when compiling on Fedora 16. So I guess we either wait for 4.1.12 or maybe create 4.1.10-r1 with the patch? Oracle (I wish I could say Sun :( ) can be relatively fast with releases, but I don't know if they deem this critical enough to actually go ahead of themselves. I'd vote for applying the patch and getting -r1 for now, though. No need to wait for a release and there is no need to revbump the existing ebuild as USE=vboxwebsrv never worked. Patch applied to the existing ebuild. You should get in in a couple of hours from your local mirror As a side note, the upstream commit does not look good as I am getting compilation errors /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libgsoapssl++.a(libgsoa pssl___a-stdsoap2_ssl_cpp.o): In function `soap_fcopy': (.text+0x340): multiple definition of `soap_fcopy' /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libgsoap++.a(libgsoap__ _a-stdsoap2_cpp.o):(.text+0x340): first defined here /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libgsoapssl++.a(libgsoa pssl___a-stdsoap2_ssl_cpp.o): In function `soap_recv_raw': (.text+0x1200): multiple definition of `soap_recv_raw' /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libgsoap++.a(libgsoap__ _a-stdsoap2_cpp.o):(.text+0x1200): first defined here /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../lib64/libgsoapssl++.a(libgsoa pssl___a-stdsoap2_ssl_cpp.o): In function `soap_recv': (.text+0x1ae0): multiple definition of `soap_recv' possibly due to multiple inclusions of the gsoap API. Hopefully they will notice in time and fix it. I apply my own patch instead |