Summary: | net-libs/xulrunner-1.8.0.4 fails to compile/install | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xake <kanelxake> |
Component: | New packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | blaisepascal, farrel.lifson |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | xulrunner ebuild with patch 113 disabled |
Description
Xake
2006-11-16 04:44:00 UTC
parrallel build isssue .. once again mozilla herd should force emerge -j1 until upstream provides assistance fixing the problem. But if this is a parallell problem is there any workaround? MAKEOPTS="-j1" seems to do no diffrence. This compilation and installation should not happen anyways. Could this be the automake issue, try removing this line from src_unpack(): WANT_AUTOCONF="2.1" \ and place it like this in the beginning of the ebuild: WANT_AUTOCONF="2.1" inherit flag-o-matic toolchain-funcs eutils makeedit multilib autotools mozconfig-2 java-pkg-opt-2 (In reply to comment #3) > This compilation and installation should not happen anyways. Could this be the > automake issue, try removing this line from src_unpack(): > WANT_AUTOCONF="2.1" \ > and place it like this in the beginning of the ebuild: > WANT_AUTOCONF="2.1" > inherit flag-o-matic toolchain-funcs eutils makeedit multilib autotools > mozconfig-2 java-pkg-opt-2 > This is not an automake issue ... even with the changes it is still sane. Didi not work for me either. remove debug from your use-flags and it should work... it is a bug, but without debug it should work for you, I'll look at it later Created attachment 103884 [details]
xulrunner ebuild with patch 113 disabled
This problem appears to be caused by the 113_xpcomglue_shared_1.patch applied during the build process. I've looked at the patch, and it appears the patch author believed that libxpcomglue_s.a is a shared-library version of libxpcomglue.a, and tried to modify the make system to make libxpcomglue.so instead of libxpcomglue_s.a. The xpcomglue and xpcomglue_s libraries are similar, but different. The web page http://developer.mozilla.org/en/docs/XPCOM_Glue explains (in Windows terminology) that xulrunner programs can link against xpcomglue_s.lib and xpcom.dll (if they need stuff in xpcom.dll) or they can link against just xpcomglue.lib (if they don't need or want a runtime dependency on xpcom.dll. The app I'm developing needs libxpcom.so, so I need libxpcomglue_s.a. If the ebuild is modified to exclude patch 113_xpcomglue_shared_1.patch.bz2, it builds properly and works. I'm attaching a modified ebuild with the erroneous patch excluded. I'm new here so I don't know if I've named/versioned the ebuild properly. Please let me know if I did it wrong. First sorry for not making anything on this, I simply don't have any time recently.. The patch is included on purpose - and it is not erroneous, simply the patches are not full - the problem is that the debug USE-flag, includes some of the tests which are not patched for this and as a result they will fail, you could exclude them in the eclass and still have debug build. The reason behind the modifying libxpcomglue to shared library and versioning it could be found on google - the patches as such are kept more or less in sync with debian :) (In reply to comment #9) > The reason behind the modifying libxpcomglue to shared library and versioning > it could be found on google - the patches as such are kept more or less in sync > with debian :) Google shows me a lot of flame-war over the "proper" way that libxpcomglue should be packaged. To tell you the truth, I don't care about what is the "proper" way or not. What I care about is that because of the decision by Debian (and thus Gentoo), I can't rely on any of the available documentation about how to develop and build XPCOM components on Gentoo systems. Mozilla says to use libxpcomglue_s.a, libxpcomglue.a and libxpcom.a and documents that approach; Debian/Gentoo says that's bogus, but I can't find documentation on how they say I should do it. I'm getting paid to do application development using xulrunner/XPCOM, not to try to figure out how well-meaning linux-purity zealots have broken the documented xulrunner build system. This ebuild appears to be useless to me and anyone else in my situation. (In reply to comment #10) > (In reply to comment #9) > > The reason behind the modifying libxpcomglue to shared library and versioning > > it could be found on google - the patches as such are kept more or less in sync > > with debian :) > > Google shows me a lot of flame-war over the "proper" way that libxpcomglue > should be packaged. To tell you the truth, I don't care about what is the > "proper" way or not. > > What I care about is that because of the decision by Debian (and thus Gentoo), > I can't rely on any of the available documentation about how to develop and > build XPCOM components on Gentoo systems. Mozilla says to use > libxpcomglue_s.a, libxpcomglue.a and libxpcom.a and documents that approach; > Debian/Gentoo says that's bogus, but I can't find documentation on how they say > I should do it. > > I'm getting paid to do application development using xulrunner/XPCOM, not to > try to figure out how well-meaning linux-purity zealots have broken the > documented xulrunner build system. This ebuild appears to be useless to me and > anyone else in my situation. > First off your attitude sucks. Second any company that is paying for xulrunner work right now is a fool. Everyone knows 1.8.0.4 is and will always be nothing more then a preview release for developers. All work should have been done against a trunk build of xulrunner. Now if you want to checkout the latest overlay work I been doing to bring xulrunner back closer to upstream you can: svn co http://overlays.gentoo.org/svn/proj/mozilla Otherwise please take your ranting elsewhere it is useless. This is only in the tree for developers, it will never see stable. Closing as WONTFIX. *** Bug 166250 has been marked as a duplicate of this bug. *** Fixed in 1.8.1.3, patchset 0.2 |