This is a request to ecopy dev-lang/v8 to Gentoo Prefix. V8 can be used instead of Spidermonkey as the JS engine behind MongoDB (if built with the v8 USE flag) and is considered to be both faster and easier to install. Reproducible: Always Steps to Reproduce:
Created attachment 262239 [details] Ecopied ebuild with some extensions for Gentoo Prefix and Mac OS X The attached ebuild is an ecopy with the following modifications: - line 73: deal with "x86-macos" architecture - line 79: pass PATH to make scons work in prefixed Gentoo - line 91: dolib and dosym the .dylib instead of .so (Mac OS X) It compiles, but dumps the QA notice: "QA Notice: invalid self-reference install_name libv8-2.5.9.15.dylib in /Gentoo/usr/lib/libv8-2.5.9.15.dylib" Here's my environment: Portage 2.2.01.17865-prefix (prefix/darwin/macos/10.5/x86, gcc-4.2.1, unavailable, 10.6.0 i386) ================================================================= System Settings ================================================================= System uname: Darwin-10.6.0-i386-32bit Timestamp of tree: Fri, 11 Feb 2011 09:12:17 +0000 distcc 3.1-toolwhip.1 i386-apple-darwin10.0 [disabled] app-shells/bash: 4.1_p7 dev-lang/python: 2.7.1-r00.1 dev-util/cmake: 2.8.3-r1 sys-devel/autoconf: 2.68 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/gcc-config: 1.4.1-r00.2 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 Repositories: gentoo_prefix bitcetera-prefix local Installed sets: @system ACCEPT_KEYWORDS="~x86-macos" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-apple-darwin9" CFLAGS="-O2 -pipe -march=nocona" CHOST="i686-apple-darwin9" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/gconf /etc/portage /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe -march=nocona" DISTDIR="/Gentoo/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps=y" FEATURES="assume-digests binpkg-logs collision-protect distlocks fixlafiles fixpackages news nostrip parallel-fetch preserve-libs protect-owned sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-dead_strip_dylibs" PKGDIR="/Gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/Gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/Gentoo/var/tmp" PORTDIR="/Gentoo/usr/portage" PORTDIR_OVERLAY="/Gentoo/var/lib/layman/bitcetera-prefix /Gentoo/usr/local/portage/local" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="aqua coreaudio cracklib cxx mmx mmxext modules ncurses nls objc objc++ prefix readline sse sse2 ssl unicode x86-macos zlib" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="Darwin" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby19" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 262525 [details] Ecopied ebuild (works on Intel Mac) The updated ebuild uses install_name_tool to fix the install_name. Kinda hacky, but it works.
Created attachment 262595 [details] Ecopied and adapted ebuild Changed the arch detection slightly to improve it for Darwin. Tested on my Intel Mac "nocona".
Patch is obsolete as you just attached usr/portage/dev-lang/v8/v8-2.5.9.15.ebuild (eg. with no modifications) Furthermore, if you can attach unified diffs (diff -u), it makes life easier.
> Patch is obsolete as you just attached > usr/portage/dev-lang/v8/v8-2.5.9.15.ebuild (eg. with no modifications) Not sure I understand. The three attachments are all different. (The identical size of the latter two is a coincidence.) Do you prefer diffs against the original or the ecopied ebuild?
Ignore me then, it is just hard to tell what is changing when a handful of lines are changed out of 100. A diff to either ecopy'd or original (just state which) - with the latter being more helpful for gentoo-x86 inclusion.
Created attachment 262793 [details] diff against original ebuild
Thank you for working on this. Some comments: - please let me review the patches before they get committed (just making sure, this is obvious) - you probably want to edit the latest ebuilds, i.e. v8-3.x (currently hard masked) - don't forget about v8-9999 ebuild; for ease of maintenance, I'd like it to look similar to other ebuilds, even if it doesn't have prefix keywords
> - please let me review the patches before they get committed Committed where? I don't have no access to prefix repos. (I need MongoDB on my prefixed Mac and thought it might be useful for others. The ebuilds I've attached here are more a starting point - I'm not really skilled with gcc and friends.)
Created attachment 263055 [details] diff against original ebuild
Created attachment 263057 [details] diff against original ebuild
Created attachment 263059 [details] diff against original ebuild
The ebuilds which are currently in the prefix tree seem not to be prefexified and don't build (on my nocona Mac).
Created attachment 263949 [details] diff against original ebuild
Created attachment 265045 [details] diff against original ebuild I've attached the diff for the latest v8 ebuild. A question though: The v8 ebuild is in the prefix tree, but without these or similar fixes won't work on Macs. Any chance my patches get applied or what would be the next step from here?
(In reply to comment #15) > A question though: The v8 ebuild is in the prefix tree, but without these or > similar fixes won't work on Macs. Any chance my patches get applied or what > would be the next step from here? Many packages are in the tree that won't work (hundreds of packages). Simple rule, if it doesn't have a keyword it hasn't been tested.
Comment on attachment 265045 [details] diff against original ebuild >+ # Explicitly import PATH for Gentoo Prefix >+ myconf+=" importenv=PATH" Could you rather add that to EXTRA_SCONS at the top of the ebuild? Also, please submit a patch against 9999 ebuild to minimize the maintenance burden for the Chromium team. After that, I guess I can just apply your patches.
Created attachment 265123 [details] updated diffs against original ebuilds (as of 2001-03-08) I've updated the ebuilds and diffed against all ebuilds currently in the tree. (Is it okay to bundle all diffs in one file or do you prefer individual attachments?)
Created attachment 265125 [details, diff] updated diffs against original ebuilds (as of 2011-03-08)
The diffs LGTM (look good to me). Prefix team, am I expected to apply them to gentoo-x86, or does the process work some other way?
hmmm, sorry, I haven't looked at the patch, but the following suggestions might improve the patch: - use get_libname from multilib.eclass to make the dolib lines unconditional (only install_name_tool remains conditional then) - not sure where myarch comes from, but perhaps a CHOST match is shorter here
Created attachment 266705 [details, diff] updated diffs against original ebuilds (as of 2011-03-21) I've updated the patches and synched them with the main portage tree. As suggested, get_libname is now being used. Furthermore, I've added a line to strip the "-macos" postfix from $myarch to obsolete the pattern matching in the if-cascade.
(In reply to comment #22) > Created attachment 266705 [details, diff] > updated diffs against original ebuilds (as of 2011-03-21) > > I've updated the patches and synched them with the main portage tree. As > suggested, get_libname is now being used. Furthermore, I've added a line to > strip the "-macos" postfix from $myarch to obsolete the pattern matching in the > if-cascade. LGTM
I'm not really happy, because the myarch hack is just nog going to get things further. Think about what happens with x64-macos, or x86-solaris. I'd prefer to see: case ${CHOST} in i?86-*) myarch=x86 ;; x86_64-*) myarch=x64 ;; *) die "unhandled arch" ;; esac or something like that
Wouldn't it be better to fix the original ebuild instead of extending the prefix patch?
(In reply to comment #25) > Wouldn't it be better to fix the original ebuild instead of extending the > prefix patch? I'm fine with switching to bash's "case" construct, but please test the arch detection logic at least in the following cases: a) x86 b) amd64 c) amd64 but compiling in 32-bit mode (this is the main reasons we need this weird logic) And I'd rather not touch this myself, but I can accept patches.
pawel, do you compile 32-bits on a system with CHOST=x86_64-pc-linux-gnu?
(In reply to comment #27) > pawel, do you compile 32-bits on a system with CHOST=x86_64-pc-linux-gnu? See bug #296917 and bug #301652. I'm not sure what's the value of CHOST in all cases. I just don't want to have a regression, and I'm not really sure how to test it myself. By the way, if we can make it more maintainable (looking at CHOST seems more elegant than looking at ARCH and ABI), that's great for me (www-client/chromium has a similar block of code).
Hmmm, this looks a lot like the multilib portage thing stuff. Apparently they loop over ABI, keeping CHOST constant. That is very annoying. In particular that our profiles don't even set ABI. I would prefer the following then: case ${CHOST} in i?86-*) myarch=ia32 ;; x86_64-*) [[ ${ABI} == x86 ]] \ && myarch=ia32 \ || myarch=x64 ;; *) die "unhandled arch" ;; esac I guess you guys are really friendly towards the multilib people. Instead they should push out some changes such that e.g. ABI is always set to make life easier.
(In reply to comment #29) > case ${CHOST} in > i?86-*) myarch=ia32 ;; > x86_64-*) > [[ ${ABI} == x86 ]] \ > && myarch=ia32 \ > || myarch=x64 ;; > *) die "unhandled arch" ;; > esac Thank you for the suggestion, it generally looks fine to me. Some comments: This does not handle arm at all. Could you add it? I think one of the problems with the original arch detection code was that ABI can be empty sometimes. Could you make sure this code can handle it? > I guess you guys are really friendly towards the multilib people. Instead they > should push out some changes such that e.g. ABI is always set to make life > easier. Possibly, I wasn't the one handling mentioned bug reports. Anyway, the current state is code that works. New changes shouldn't cause regressions.
just add an arm*-*) case statement with the correct myarch setting for v8 Since ABI is empty for most people (apparently, that was what the second bug was about), my code assumes it is only optionally set when relevant (amd64), and in that case triggers 32-bits mode. See the logic, if it's absent or not x86, it falls in x64 mode. My suggestion should be fully backwards compatible, by retaining the behaviour as was (ABI was ARCH by default default, now ARCH is replaced by CHOST check to make selection over multiple OSs easier)
ferret, Giacomo: feel free to comment on planned changes to arch detection logic. This is going to affect both chromium and v8. The resulting changes look good to me, but I'd like to wait a bit, because the recent frequent updates of the dev channel look like trying to stabilize before shipping beta. When we have the next "big" dev channel update, I'm going to try those changes. (In reply to comment #31) > just add an arm*-*) case statement with the correct myarch setting for v8 Sounds good. > Since ABI is empty for most people (apparently, that was what the second bug > was about), my code assumes it is only optionally set when relevant (amd64), > and in that case triggers 32-bits mode. See the logic, if it's absent or not > x86, it falls in x64 mode. Ah, I see. Fine then. > My suggestion should be fully backwards compatible, by retaining the behaviour > as was (ABI was ARCH by default default, now ARCH is replaced by CHOST check to > make selection over multiple OSs easier) Also sounds good.
chromium-12.x now uses the new arch detection logic, testing would be appreciated. I plan to apply it to v8 later.
My gentoo amd64 box with multilib and xgcc on it recently exploded and I haven't got around to installing it on my new laptop yet, so I won't be able to test it. I will have a look at the patches at some point soon, though, as I already did a bunch of research on this for the portage-multilib overlay.
Okay, v8-3.2.x uses the new arch detection logic. Prefix team, your move.
v8 keyworded and imported now, thanks all
